GCC Developers Look At Transitioning Their Codebase To C++11

[phoronix]

Phoronix: GCC Developers Look At Transitioning Their Codebase To C++11

Seven years after the GNU Compiler Collection (GCC) developers began transitioning their codebase from C to C++, they are now discussing the prospects of adopting C++11 as their allowed C++ standard revision for developing this open-source compiler...

http://www.phoronix.com/scan.php?page=news_item&px=GCC-Transition-Codebase-Cpp11

[tildearrow]

I agree upon this change.
I generally wait ~5 years after a new C++ version before adopting it.

[carewolf]

I wished they had refactored more with to C++ already. They still have some ugly C'isms that would be much nicer in C++. I like GCC and contribute more often to it than clang, but the clang code is much nicer due to being more modern and more C++.

[yoshi314]

I wished they had refactored more with to C++ already. They still have some ugly C'isms that would be much nicer in C++. I like GCC and contribute more often to it than clang, but the clang code is much nicer due to being more modern and more C++.

newer c++ (17/20) is significantly better than older revisions. sometimes it might make more sense to put things off for a while, instead of refactoring after each c++ standard iteration.

[AsuMagic]

newer c++ (17/20) is significantly better than older revisions. sometimes it might make more sense to put things off for a while, instead of refactoring after each c++ standard iteration.

I wouldn't put C++17 and C++20 next to each other. C++20 is an absolutely massive change, probably as large as C++11 was.
C++14 and C++17 IMO only were (welcomed) small or average improvements over C++11.
C++20 is definitively going to be great because of modules, concepts and a lot of other things.

But for that reason, I don't see the harm into bumping up to C++14/17 rather than C++11 other than portability (which may be somewhat important for a self-hosted compiler): You don't really need to refactor the entire codebase to remain consistent. You can start using constexpr in a few more places, use if constexpr to get rid of some horrible workarounds, you can start using user-defined literals, etc.
I haven't looked at whether they discussed C++14/17 so there might be more things I'm missing out.

[carewolf]

newer c++ (17/20) is significantly better than older revisions. sometimes it might make more sense to put things off for a while, instead of refactoring after each c++ standard iteration.

Doesn't matter that much for the subset GCC uses, and they need to rely on pretty old versions to be portable.

[ermo]

From an outside and non-C++ programmer perspective, it seems to me that if C++14/17 are small-ish revisions over C++11 and gcc needs to be self-hosting on older gcc versions, it makes perfect sense to first try to bring in the most valuable features (C++11 apparently), since the upgrade path to a C++14/C++17 feature-baseline could be a relatively easy one later on, when the gcc self-hosting needs change due to the passage of time and older platforms with older gcc versions fall out of active enterprise use.

Could someone knowledgeable shed some light on the primary benefits and the parts of gcc where these benefits would yield the biggest maintenance/readability improvement? I'm going to naively assume that better maintainability and readability could even help expose bugs and misfeatures during such a rewrite...

[elatllat]

rust

...could even help expose bugs...

😈

[L_A_G]

While C++17 and 20 don't contain any fundamental level changes, I've personally found that at least C++17 contains loads of really handy stuff pulled from places like the Boost library. Needed to do some disk IO recently and found that the Filesystem library is a really good tool and you don't even need to pull in Boost anymore when you're working with a recent version of GCC.

A few years ago I needed to parallelize a pretty heavily single threaded C++ application and as it was already being compiled with a fairly recent version of GCC I didn't even need to pull in anything new when I used the multi-threading additions they made to C++11. I was also wondering why getting GCC properly multi-threaded seemed to be such a big task and if they're stuck on ISO original C++ (98) or 03, then that does make a whole lot more sense.

[paulpach]

I look forward to c++20, it is shaping up to be such a breath of fresh air. Modules, Concepts, Ranges. Ranges look like an absolute fantastic productivity enhancement.