

GCC: Patch to change default C++ dialect to C++14 - nly
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00073.html

======
Someone1234
This might be a terrible idea, but maybe it is a good time to scrap the
concept of a default completely.

Wouldn't it be more future proof just to FORCE everyone to have to specify
which language version they're targeting? That way when a new one is added it
has absolutely no impact on the historical ones.

It isn't like c++14 is going to be the last version ever.

PS - If GCC is still in use in 2098 then things may get awkward.

~~~
frozenport
>>just to FORCE everyone to have to specify which language version they're
targeting?

There is a thought.

I see a lot of trouble from this proposal because the compilers and supplied
libraries have a history of including extra things. Until quiet recently C++
headers would drop in C that nobody asked for. Personally, I was surprised to
find that on Windows I could throw std::runtime_error.

At the end of the day a lot of code would break, because nobody is sure
exactly what standard they are actually are using.

~~~
kbenson
Is there a technical reason that would prevent the compiler from honoring a
per-file pragma that allowed the developer to define how the code was expected
to be interpreted by the compiler?

~~~
eru
Haskell's GHC is doing exactly that. You can even mix and match pragmas for
different extensions.

~~~
Argorak
I find it terribly confusing. It means that Haskell is almost never something
I can expect a lot from, but a weird combination of extensions changing to
"non-standard" behaviours.

~~~
eru
Never confused me. In general, on a bigger project you'll have a bunch of
approved extensions, and everything extra goes through very strict code review
to see whether it helps more than it confuses.

~~~
Argorak
In a strictly controlled project, fine. But working with three different open
source extensions that all use a different setup gets confusing quickly.

Point being the same: Haskell as used is never quite standard Haskell.

~~~
codygman
> Point being the same: Haskell as used is never quite standard Haskell.

In practice I haven't found this true.

------
santaclaus
How long before this happens on Clang?

~~~
BudVVeezer
It's something we're discussing and exploring. The general thought is that
Clang could do this for everything but sized deallocations (and it's unclear
how much of an issue those would pose).

~~~
scotty79
C++14 is awesome language, I didn't have much contact with C++ development for
over a decade but I keep one eye on how C++ develops and am amazed of how
flexible things became without abandoning strictness altogether C# "dynamic"
kind of way.

Keeping strictness in the language allows for awesome tooling so I tried
yesterday to find good IDE for C++14. There's not much on the market. Clion is
decent but doesn't handle code completion for auto return type.

Clang does, so Atom code editor with clang based auto-complete plugin works
better than Clion.

But I have luck for finding issues in the things I touch so I immediately
encountered something that's not supported by clang autocomplete. It turned
out of course that I'm not the first one to encounter this issue:
[https://llvm.org/bugs/show_bug.cgi?id=14446](https://llvm.org/bugs/show_bug.cgi?id=14446)

Since it's hanging there since 2012 I understand it's a low priority issue.
Could you give me any pointers of how could I help with implementing this
feature? Maybe point me to files that I'd need to alter to attempt to
implement this?

------
cosarara97
Won't this break stuff?

~~~
cremno
Maybe. For example, GCC 5 changed the default for C from gnu89 to gnu11 and
that broke the build of some Finnish amateur project:

[https://lkml.org/lkml/2014/10/19/94](https://lkml.org/lkml/2014/10/19/94)

That's why projects that use GCC or a compatible compiler should use the -std
option to set the targeted standard and not rely on the default.

~~~
ajross
Pretty much. Taking the "will this break stuff?" worry to the logical extreme
would mean that gcc should default to a pre-standarization K&R dialect and g++
to a cfront dialect contemporary with 1st edition Stroustrup.

The world moves on. Though if you're an active project, moving along with the
world is probably a better option than throwing in --std=c++really-old and
deliberately refusing to use new stuff.

------
ndesaulniers
OH: "Now for updating the default C std"

