GCC Begins Preparing For C++20 With -std=c++2a

[onicsis]

From the main compiler list, from https://en.wikipedia.org/wiki/List_o...B.2B_compilers, it seem that only Cland and GCC are compliant with C++14 and C++17.

[cl333r]

let's turn C++ into COBOL because people manning big projects can't simply show they have a brain and target a stable feature level with their code.

That's communism, sheer communism I say.

Communism is when people eat little children, incest and don't believe in the Great Jesus Christ who saved anyone except non-Christians.

[RealNC]

In my opinion. It's too much. If this is the new norm for C++, it may very well harm C++'s reputation as a powerful, solid and stable language. The reputation will become: bleeding edge risky language with inconsistent compiler support. I can even imagine hideous preprocessors checking compiler versions to ensure certain features even work or work correctly (for developers considerate of their users anyway).

The changes from 03 to 11 were huge. The 3-year cycle means less drastic changes. The whole point of this is to avoid repeating the issues the 03->11 jump had.

This is actually making the language more stable, not more unstable. Smaller, incremental changes easy to cope with, rather than a huge mountain of "here's what's different" breakage.

This improves your ability to pick which features you want to target. If you only had C++11 vs C++20, your only options are either 11 or 20. With the new model, you can pick 14 if you want, without having to go the "all or nothing" way. This also allows compilers to implement the spec faster.

[caligula]

Well, you can always wait a bit before using the newest features. Let the compilers implement them. E.g. avoid anything higher than C++14 for now.

I'd assume his research relied on some new features. Otherwise he would have not used them?

[cj.wijtmans]

Communism is when people eat little children, incest and don't believe in the Great Jesus Christ who saved anyone except non-Christians.

communism is when you kill 100 million people. Invade half of germany and starve them to death after you starved the ukraine to death. After killing a lot of people because they believe in something stupid you dont agree with. Then use your rich bankers throughout europe to promote communism in conservative liberal societies under neoliberalism and progressivism. Then starve even more people to death while you invade europe and get the french to invade germany as well. Then the germans standing up to it are the bad guys, them telling the truth is nothing but false and racist propaganda. Then america finally helps to rid the nazis once and for all. Then you infiltrate and take over all the media and universities to create an even deeper propaganda that people become self hating cucks that think that anyone stands up for their people, country or even has slight criticism is a racist, sexist shitlord that is antiscience while you believe in 349572348 genders. Oh, does the rabit lair of the white red eyed killer bunny collecting two faced coins go deep.

[stephen82]

I can appreciate the C++ compiler developers are aggressively keeping up with drafts of future standards. And I appreciate that the C++ standards committee is improving/extending the language. But I don't appreciate that the C++ language has evolved from a stable language to a beta/draft language. In my opinion, these 2-3 year revision cycles are way too frequent for a language like C++. I think it should be more like 8-10 year update cycles (e.g. C++03 to C++11) so that the language upholds its reputation as a rock solid stable language and developers can master the new features without having to wonder about all these other draft features. They also have to think less about compiler support headaches. Now-a-days, I find myself checking if VS20## supports C++## feature since I try to write code compatible with lots of compilers across Linux and Windows.

In graduate school, I had a friend using some C++0x draft features for his research and I think some of those changes were revised, removed or changed and that really bit him one or two times. That was C++03 to C++11! Now we have C++11 to C++14, C++14 to C++17, C++17 to C++20. Compilers are implementing the draft features as soon as they're proposed and some developers and projects are early adopters. The draft features can and do proliferate in the open source scene and wreak havoc by being revised, changed, or removed and inconsistent compiler support across all the different operating systems can cause all sorts of burdens on end users and developers.

In my opinion. It's too much. If this is the new norm for C++, it may very well harm C++'s reputation as a powerful, solid and stable language. The reputation will become: bleeding edge risky language with inconsistent compiler support. I can even imagine hideous preprocessors checking compiler versions to ensure certain features even work or work correctly (for developers considerate of their users anyway).

As much as I hate to admit it, as a C++ zealot I wholeheartedly agree with you.

It took me years to fully understand the basics, let alone to get a rough idea how the rest of the language works.

I can honestly admit that I know approximately the 0.1% of the language and I feel this whole thing is getting out of control.

Since C++ is a multi-paradigm language, each new feature added in to the language adds an extra level of complexity on every paradigm it supports and instead of finally paying attention to the newcomer to teach him or her the right way to use the language, based on the case of use, they add more features that confuse the hell out of people, especially the new candidates that want to try "the new, modern C++".

Yes, I love these new features, such as auto, decltype(auto), move semantics, lambdas, constexpr, and all the new fancy features that have got added to the language.

What I don't like though is that I feel I'm getting bombarded with language improvements at an outrageously fast pace that takes a great amount of time to understand how they work, let alone to digest and have to catch up with freshly graduates that have a spongy brain that absorbs anything in zero time.

Bloody hell I'm old and grumpy! -_-

[nslay]

Thanks to everyone for all their responses to my comment!

As much as I hate to admit it, as a C++ zealot I wholeheartedly agree with you.

It took me years to fully understand the basics, let alone to get a rough idea how the rest of the language works.

I can honestly admit that I know approximately the 0.1% of the language and I feel this whole thing is getting out of control.

Since C++ is a multi-paradigm language, each new feature added in to the language adds an extra level of complexity on every paradigm it supports and instead of finally paying attention to the newcomer to teach him or her the right way to use the language, based on the case of use, they add more features that confuse the hell out of people, especially the new candidates that want to try "the new, modern C++".

Yes, I love these new features, such as auto, decltype(auto), move semantics, lambdas, constexpr, and all the new fancy features that have got added to the language.

What I don't like though is that I feel I'm getting bombarded with language improvements at an outrageously fast pace that takes a great amount of time to understand how they work, let alone to digest and have to catch up with freshly graduates that have a spongy brain that absorbs anything in zero time.

Bloody hell I'm old and grumpy! -_-

IDE support aside, I'm waiting for an auto considered harmful article. Yeah, I get that type information is still there and that the compiler knows everything it needs to know about the code. I especially value it for scoped types from classes (particularly those with unresolved template arguments). But the dumb human using the compiler doesn't necessarily know what's being passed around without either the help of an IDE or reading the code for, at worst, a long chain of function calls to figure out what the hell type is being returned. I honestly try to minimize the use of auto to improve readability and only opt to use it when it actually improves readability. Otherwise, readability can be as bad as non-type-safe languages. Just my opinion.

I completely agree with you about lambdas and constexpr though.

It's not only about allowing developers and compiler implementations time to master and stabilize the features. It's also about early adopting open source projects and older systems with older compilers. Those early-adopting projects might even be relatively well-used optional dependencies for other projects! And what a nightmare to think that 5-10 years from now, someone using your code might still be using a compiler with draft C++14 or even draft C++17 features (with bugs or changes in their implementations!). Or worse, Microsoft's compilers are always sluggish with standards. This can and does haunt even smart developers. I reiterate my opinion that 2-3 year standards revisions are too frequent.

[pal666]

Let's hope clang (or somebody else) implements concepts this time, so it concepts isn't once again removed from gcc's switch like it was from c++0x and c++1z.

in c++0x there were no concepts in the standard. in c++20 there are concepts in the standard. every compiler will implement them

[pal666]

I don't appreciate that the C++ language has evolved from a stable language to a beta/draft language.

just say no to drugs.

In my opinion, these 2-3 year revision cycles are way too frequent for a language like C++. I think it should be more like 8-10 year update cycles (e.g. C++03 to C++11) so that the language upholds its reputation as a rock solid stable language and developers can master the new features without having to wonder about all these other draft features.

you have insanely idiotic opinion. c++ already had long update cycle and it was a disaster. new update cycle is time based, not feature based. ready features ship, not ready ones postponed. but good news is committee will not take into account opinions of idiots

Now-a-days, I find myself checking if VS20## supports C++## feature since I try to write code compatible with lots of compilers across Linux and Windows.

how your idiotic idea will help you? msvc will lag and will add some features each new release no matter how long standard release cycles will be

In graduate school, I had a friend using some C++0x draft features for his research and I think some of those changes were revised, removed or changed and that really bit him one or two times. That was C++03 to C++11!

don't use draft features if it hurts, imbecile

Now we have C++11 to C++14, C++14 to C++17, C++17 to C++20. Compilers are implementing the draft features as soon as they're proposed and some developers and projects are early adopters.

imbecile, if next c++ is going to be c++30, it will only make matters worse. draft features will come and go and early adopters will suffer even more

In my opinion.

go back to school ffs

[pal666]

I would actually love a way to add library-extensions backwards, say use C++17 std::size in C++11. Its does not need any C++17/C++14 language features.

just compile c++11 code with -std=c++17 switch, problem solved