LLVM Clang 6.0 Now Defaults To C++14

[phoronix]

Phoronix: LLVM Clang 6.0 Now Defaults To C++14

Up to now LLVM's Clang C/C++ compiler has defaulted to using C++98/C++14 as its default C++ standard, but fortunately that's no more...

http://www.phoronix.com/scan.php?pag...Clang-60-CPP14

[wizard69]

Does matching GCC in this context make sense? I can understand the desire to be command line compatible in most cases but in thus case it just feels regressive. Beyond that does C++17 throw that many compatibility curves, that is features that break older legal code?

[RealNC]

Up to now LLVM's Clang C/C++ compiler has defaulted to using C++98/C++14 as its default C++ standard

That doesn't make any sense :-P

[Michael]

That doesn't make any sense :-P

Fixed, thanks. Had intended as "C++98/GNU++98"

[Xelix]

Does matching GCC in this context make sense? I can understand the desire to be command line compatible in most cases but in thus case it just feels regressive. Beyond that does C++17 throw that many compatibility curves, that is features that break older legal code?

I think it's a sensible decision: Clang is trying to ensure that code written against gcc works fine with as little modification as possible on Clang.

I can't think of anything in C++17 that breaks legal C++14 code, apart from removing a couple of deprecated stuff from the standard library.

[gufide]

I think it's a sensible decision: Clang is trying to ensure that code written against gcc works fine with as little modification as possible on Clang.

I can't think of anything in C++17 that breaks legal C++14 code, apart from removing a couple of deprecated stuff from the standard library.

There are some corner cases. For example, classes with base classes can still be aggregates. That means this code breaks, whereas I worked before:

struct A{ protected: A(){} };
struct B : A {};
B b{};

And also there's P0522R0 breaking code, which clang disable by default. https://stackoverflow.com/questions/...-breaking-code

Also, if you ever did function type introspection, you'd have to update your code for the 26 possible new function pointer types.

[discordian]

I tested using C++17 on a C++11 codebase and code compiled but behaved differently during runtime. Can`t really fault C++17 (using namespace std is a horrible but common crime), the reason was that new std::empty was being used instead of an own empty function with different semantics.
So there is enough that can go wrong.

[carewolf]

I think it's a sensible decision: Clang is trying to ensure that code written against gcc works fine with as little modification as possible on Clang.

I can't think of anything in C++17 that breaks legal C++14 code, apart from removing a couple of deprecated stuff from the standard library.

If you have function to a noexcept declared function and cakes the address of it, the type now includes the noexcept part in C++17. It breaks some code, though fortunately it is a corner case. There are one or two other special casess that were broken.