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

[nanonyme]

Do also considering the bootstrappability requirement. You need an older GCC to build a newer GCC and unless you can have quite large version difference between the two, it will be quite painful for LTS distros.

[kpedersen]

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

Agreed. I often have to slap a couple of "fresh and less experienced" developers down when they want to use all the latest "coolness" in a project.
Mainly because these language over-consumers then just sit there blaming their tools if they ever have to port the codebase to a slightly more exotic platform with an older standard compiler.

Traditionally that is why I have always preferred important tools like GCC to be written in boring old C because it pretty much eliminates the risk of someone saying "but [insert niche trendy feature] is sooooo coooool I wish they would use it all over the codebase making it unportable and awkward to quite a few platforms that isn't Linux".

[Entryhazard]

I'm surprised actually, I was convinced GCC was using C++11 since the first transition to C++ as it was the turning point that made C++ rather convenient to use as a language

[TheOnlyJoey]

Ugh bad changes imho.
I personally really dislike 'modern' c++ variations (Program in C++03 as much as i can when deciding to use C++ over C99), and it is sad to see software i use on a daily base are adopting lazyness over function.
Well time to fork i guess.

[cl333r]

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

Something's wrong with the like system, I hit like a few hours ago but currently it shows zero likes and the "unlike" option. Can't post a screenshot because phoronix doesn't accept uploading images to it and too lazy to use an uploading service.

[coder]

I personally really dislike 'modern' c++ variations (Program in C++03 as much as i can when deciding to use C++ over C99), and it is sad to see software i use on a daily base are adopting lazyness over function.

Like what? The only "lazyness" feature that comes to mind is auto, and I agree that people tend to overuse it. But, there's nothing wrong with range-based for-loops, which don't require you to use auto, if you'd prefer to be explicit about the type of your loop variable (as I often do).

C++11 has a lot of great stuff, including pulling in lots of Boost mainstays that are improved through better language support - things like "move", bind, and lambdas. I use these not out of laziness, but because they give me more expressive power and enable me to work at a more appropriate level of abstraction for many tasks. And things like "move" and constexpr are good examples of cases where more semantic richness actually leads to more efficient code - not less.

[Vistaus]

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

Companies must not like you very much lol

[Vistaus]

rust
😈

[Vistaus]

With so many people disliking using the latest and greatest (in this case C++20) for coding, instead using older versions for a while longer, I wonder if anybody even uses the latest and greatest?

[AsuMagic]

Ugh bad changes imho.
I personally really dislike 'modern' c++ variations (Program in C++03 as much as i can when deciding to use C++ over C99), and it is sad to see software i use on a daily base are adopting lazyness over function.
Well time to fork i guess.

Seriously, I don't get why you decide to stay on an antique standard. Even hardcore anti modern C++ zealots I have seen do not immediately reject C++11 and newer standards.
They pick up what they think is fine (even if that is a needlessly shortened list). Rejecting modern standards for everything just because you think it's about laziness is foolish.
Stay in your world of buggy software and CVEs if you want. There's a reason why languages like Rust are moving forward and that C++ is trying to catch up where it is relevant.

• Manual memory allocations are essentially always a terrible idea.
  Most of the time you can do the job with unique_ptr and it will neatly manage the lifetime of the held object.
  Seriously, if it's anything, it's not laziness. There are so much use-after-free bugs and memory leaks in the real world that could have been avoided with smart pointers.
• Threading is a pain in the ass without C++11. Most people used Boost threading or just directly used pthread or win32 threading.
  The former is a massive dependency, the latter is a portability issue, and it's not any nice to work with.
• Even on the simplest stuff C++03 is annoying: No initializer lists, the stupid > > syntax rule, being unable to call a parent constructor or inherit from them...
• For-range loops are a godsent. Seriously. How can you not prefer this
  

  for (const auto& [key, value] : my_container)
  	{
  	// use key and value
  	}

  over this?
  

  	for (std::map<MyKey, MyValue>::const_iterator it = my_container.begin(); it != m_container.end(); ++it)
  	{
  	// use it->first and it->second
  	}

  And that's just an irrealistic example. In practice it's even more annoying to have a jungle of it->first and it->second within a line. It doesn't make anything less readable.
• I don't want to have to pull a separate library to deal with something as basic as time. Say what you want about <chrono>, but it does what I want to and does that pretty well.
• Move semantics are great. It actually makes RAII bearable in many instances where it wasn't.
  I don't want to free up resources manually much like I don't want to have to deal with memory allocations manually.
• Lambdas, again, are a godsent. Why do you prefer, say

  void my_comparison_function(const Something& a, const Something& b) const
  	{
  	return a.foo < b.foo;
  	}
  	
  	void some_function()
  	{
  	// Possibly lots of code that makes my_comparison_function much further separated
  	std::sort(some_container.begin(), some_container.end(), my_comparison_function);
  	}

  over this?
  

  	std::sort(some_container.begin(), some_container.end(), [](const Something& a, const Something& b) {
  	return a.foo < b.foo
  	});

  or soon, even this?
  

  std::ranges::sort(some_container, [](const Something& a, const Something& b) {
  	return a.foo < b.foo
  	});

• auto is not only useful for "laziness". It is very convenient for metaprogramming, and allows avoiding needless verbosity or workarounds. With if constexpr too, you can make so much code more maintainable and readable without having to parse dozens of lines of SFINAE bullshit.
• constexpr is just really convenient. Unfortunately IMO it does not go as extensive as I want it to be, but it is going to improve a fair bit in C++20 and probably in other future standards. I find it comparable to Haskell's purity concept in a very good way.
• I take std::array so much for granted that I forgot that it was not a thing in C++03. Seriously, if you still are willingly using C-style arrays in 2019, I just don't ever want to have to deal with your code. I never ever found any reason not to use that other than pure masochism.
• Moving forward, modules are going to be one hell of an upgrade. I don't know about you but I'm not exactly a fan of having to micro-optimize declarations and definitions between .cpp and .hpp files by fear of bumping up compile time. And there is so much more that makes includes a PITA.
  Yes, compile time had been an increasing problem in newer standards because the standard library grew and allowed constructs that were a bit heavier on the compiler, but this is absolutely going to be a thing of the past.

In every point I made, there is no loss of functionality or performance. Either it is the opposite because it allows making the syntax cleaner and safer at no cost (and enables better maintainability, readability, sometimes optimizations, etc.) or because they were outright designed to make performance better (move semantics, constexpr, modules).

Of course your wish to fork is likely to just be a thing you say on forums and not do in practice because you are pissed off but...
Why would you want to fork a compiler on your own just because they bumped the standard number? Complete and utter waste of resources for a meaningless fight.
Cause, hell, I absolutely did not agree with those angry about the Linux CoC and willing to fork, but at least that had a reasonable motivation behind it.

(EDIT: Ignore the indent in the code blocks, it's because of the WYSIWYG editor. Don't worry, I'm not the kind of masochistic people who write in GNU style)