Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC 16 considering changing default to C++20

inbox.sourceware.org

Post reply on HN
Print view View original

51–60 of 119 posts

Re: GCC 16 considering changing default to C++20

#51

Post by ziotom78 »

cogman10 wrote: post #50
quietbritishjim wrote: post #49

Earlier quoted context omitted.

> ... why would you do it when you can simply keep the compiler targeting 11 ... It doesn't appear to me that the parent comment was implying otherwise. The default is changing for any compilation that doesn't explicitly specify a standard version. I would have thought that the build process for a compiler is likely careful enough that it does explicitly specify a version.

> It's the type of dog fooding they should be doing! It's one reason why people care so much about self-hosted compilers, it's a demonstration of maturity of the language/compiler. I could be misreading this, but unless they have a different understanding of what it means to dog fooding than I do then it seems like the proposal is to use C++20 features in the compiler bootstraping.

I believe they are really referring to the default mode used by GCC when no standard is explicitly stated.

The email mentions that the last time they changed it was 5 years ago in GCC 11, and the link https://gcc.gnu.org/projects/cxx-status.html#cxx17> indeed says

> C++17 mode is the default since GCC 11; it can be explicitly selected with the -std=c++17 command-line flag, or -std=gnu++17 to enable GNU extensions as well.

which does not imply a change in an obscure feature (bootstrapping) that would only affect a few users.

Re: GCC 16 considering changing default to C++20

#52

Post by binary132 »

withzombies wrote: post #10

Shouldn't the compilers be on the bleeding edge of the standards? What is the downside of switching to the newest standard when it's properly supported? It's the type of dog fooding they should be doing! It's one reason why people care so much about self-hosted compilers, it's a demonstration of maturity of the language/compiler.

A lot of software, and thus build automation, will break due to certain features that become warnings or outright errors in new versions of C++. It may or may not be a lot of work to change that, and it may or may not even be possible in some cases. We would all like there to be unlimited developer time, but in real life software needs a maintainer.

Re: GCC 16 considering changing default to C++20

#53

Post by dagmx »

withzombies wrote: post #10

Shouldn't the compilers be on the bleeding edge of the standards? What is the downside of switching to the newest standard when it's properly supported? It's the type of dog fooding they should be doing! It's one reason why people care so much about self-hosted compilers, it's a demonstration of maturity of the language/compiler.

This is about changing the default.

The issue with defaults is that people have projects that implicitly expect the default to be static.

So when the default changes, many projects break. This is maybe fine if it’s your own project but when it’s a few dependencies deep, it becomes more of an issue to fix.

Re: GCC 16 considering changing default to C++20

#54

Post by mustache_kimono »

superkuh wrote: post #41
withzombies wrote: post #10

Shouldn't the compilers be on the bleeding edge of the standards? What is the downside of switching to the newest standard when it's properly supported? It's the type of dog fooding they should be doing! It's one reason why people care so much about self-hosted compilers, it's a demonstration of maturity of the language/compiler.

When a language changes significantly faster than release cycles (ie, rust being a different compiler every 3 months) it means that distros cannot self-host if they use rust code in their software. ie, with Debian's Apt now having rust code, and Debian's release cycle being 4 years for LTS, Debian's shipped rustc won't be able to compile Apt since nearly all rust devs are bleeding edge targeters. The entire language…

> Debian's shipped rustc won't be able to compile Apt since nearly all rust devs are bleeding edge targeters.

This is nonsense. Apt devs can target a rustc release and that release can be the same release that ships with Debian? Moreover, since those apt devs may have some say in the matter, they can choose to update the compiler in Debian!

> The entire language culture is built around this rapid improvement.

... Because this is a cultural argument about how some people really enjoy having their codebase be 6 years behind the latest language standard, not about any actual practical problem.

And I can understand how someone may not be eager to learn C++20's concepts or to add them immediately to a code base, but upgrades to your minimum Rust version don't really feel like that. It's much more like "Wow that's a nifty feature, I immediately understand and I'd like to use in the std lib. That's a great alternative to [much more complex thing...]" See, for example, OnceLock added at 1.70.0: https://doc.rust-lang.org/std/sync/struct.OnceLock.html

Re: GCC 16 considering changing default to C++20

#55

Post by naIak »

windward wrote: post #28
suby wrote: post #8

Earlier quoted context omitted.

I think if you were to poll people, a significant portion would be repulsed by this catgirl aesthetic, or (though this isn't the case for Anubis) the cliche inappropriately dressed inappropriately young anime characters dawned as mascots in an ever increasing number of projects. People can do whatever they want with their projects, but I feel like the people who like this crap perhaps don't understand how repulsive i…

The internet was better when it repulsed a significant portion of people.

What would happen if it changed in a way that repulsed you?

Re: GCC 16 considering changing default to C++20

#56

Post by MichaelZuo »

dagmx wrote: post #53
withzombies wrote: post #10

Shouldn't the compilers be on the bleeding edge of the standards? What is the downside of switching to the newest standard when it's properly supported? It's the type of dog fooding they should be doing! It's one reason why people care so much about self-hosted compilers, it's a demonstration of maturity of the language/compiler.

This is about changing the default. The issue with defaults is that people have projects that implicitly expect the default to be static. So when the default changes, many projects break. This is maybe fine if it’s your own project but when it’s a few dependencies deep, it becomes more of an issue to fix.

That sounds more like a problem of nonsensical assumptions… what possible expectation could there have been that GCC would never change this in the future?

Re: GCC 16 considering changing default to C++20

#57

Post by maxlybbert »

rmu09 wrote: post #39
cogman10 wrote: post #17

Earlier quoted context omitted.

There's a bootstrapping process that has to happen to compile the compiler. Moving up the language standard chain requires that compilers compiling the compiler need to also migrate up the chain. So you can never be perfectly bleeding edge as it'd keep you from being able to build your compiler with an older compiler that doesn't support those bleeding edge features. Imagine, for example, that you are debian and you…

Aren't they talking about the c++ dialect the compiler expects without any further -std=... arguments? How does that affect the bootstrapping process? This https://gcc.gnu.org/codingconventions.html should define what C/C++ standard is acceptable in the GCC.

Correct, this is a discussion of which language version the compiler should follow if the programmer doesn’t specify one. It’s not about which features are acceptable when implementing the compiler.

Re: GCC 16 considering changing default to C++20

#58

Post by surajrmal »

superkuh wrote: post #41
withzombies wrote: post #10

Shouldn't the compilers be on the bleeding edge of the standards? What is the downside of switching to the newest standard when it's properly supported? It's the type of dog fooding they should be doing! It's one reason why people care so much about self-hosted compilers, it's a demonstration of maturity of the language/compiler.

When a language changes significantly faster than release cycles (ie, rust being a different compiler every 3 months) it means that distros cannot self-host if they use rust code in their software. ie, with Debian's Apt now having rust code, and Debian's release cycle being 4 years for LTS, Debian's shipped rustc won't be able to compile Apt since nearly all rust devs are bleeding edge targeters. The entire language…

The problem you mention is perhaps a sign that the model Debian uses is ill suited for development. Stable software is great but it need not impede progress and evolution. It's also possible to support older rust compiler versions if it's important - apt developers can do the work necessary to support 4yo lts compilers.

Re: GCC 16 considering changing default to C++20

#59

Post by reactordev »

dagmx wrote: post #53
withzombies wrote: post #10

Shouldn't the compilers be on the bleeding edge of the standards? What is the downside of switching to the newest standard when it's properly supported? It's the type of dog fooding they should be doing! It's one reason why people care so much about self-hosted compilers, it's a demonstration of maturity of the language/compiler.

This is about changing the default. The issue with defaults is that people have projects that implicitly expect the default to be static. So when the default changes, many projects break. This is maybe fine if it’s your own project but when it’s a few dependencies deep, it becomes more of an issue to fix.

If you’re relying on defaults, and upgrade, that is entirely your fault. Don’t hold everyone in the world back because you didn’t want to codify your expectations.

Re: GCC 16 considering changing default to C++20

#60

Post by jayd16 »

MichaelZuo wrote: post #56
dagmx wrote: post #53

Earlier quoted context omitted.

This is about changing the default. The issue with defaults is that people have projects that implicitly expect the default to be static. So when the default changes, many projects break. This is maybe fine if it’s your own project but when it’s a few dependencies deep, it becomes more of an issue to fix.

That sounds more like a problem of nonsensical assumptions… what possible expectation could there have been that GCC would never change this in the future?

The assumption is along the lines of "this works so why should I ever think about it again if I don't have to?"

It's not an end user problem, anyway. The issue is the language didn't change in a backwards compatible way and also didn't require setting a language version.

Post reply on HN