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

101–110 of 119 posts

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

#101

Post by stabbles »

eddd-ddde wrote: post #96
cogman10 wrote: post #45

Earlier quoted context omitted.

> as long as the C++ sources of GCC are compatible with older and newer versions of the C++ standard. I've worked on a number of pretty large projects. If the target for the source code changes it can be really hard to keep C++20 features from creeping in. It means that you either need to explicitly build targeting 11, or whoever does code reviews needs to have encyclopedic knowledge of whether or not a change leaked…

The answer is obvious, YES, specify your language version. Every single compiler invocation for production (for example ci builds) should explicitly select a version. Otherwise you are asking for trouble.

Yeah, developers should specify what language and dialect a project is written in. In practice though, support for that in build systems is cumbersome.

For example in CMake the natural variable is CMAKE_CXX_STANDARD, but it's implemented backwards: if you set it to 14 but your compiler supports only C++11, they'll add -std=gnu++11. You have to also set CMAKE_CXX_STANDARD_REQUIRED to ON, which not man projects do. I don't think there's an easy way to say "this project requires C++14 or higher".

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

#102

Post by nomel »

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.

Do you have an example? Adding the `--std=` flag should work, which you should already be using anyways. Is the issue that you don't want to use that argument?

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

#103

Post by rossy »

suby wrote: post #8
f1refly wrote: post #5

Earlier quoted context omitted.

Right? I hope it never goes away, we should make the web more fun instead of sad and clean!

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…

> (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

I think the fact that people bring up things that the Anubis mascot isn't when talking about Anubis is more telling of their own harmful (and potentially racist) biases against Japanese-styled media than it is about the idea of having anime-styled mascots for free software projects.

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

#104

Post by pjmlp »

Maxatar wrote: post #100
pjmlp wrote: post #99

Earlier quoted context omitted.

Today I learnt that Office is an hobby project.

You learned nothing because the extent of your knowledge tends to be rather superficial when it comes to C++. Office does not use C++ modules, what Office did was make use of a non-standard MSVC feature [1] which reinterprets #include preprocessor directives as header units. Absolutely no changes to source code is needed to make use of this compiler feature. This is not the same as using C++20 modules which would req…

My dear, I have written more C++20 modules code than you ever will.

Feel free to roam around on my Github account.

Also go read the C++ mailings regarding what is standard or not in modules.

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

#105

Post by burnt-resistor »

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.

Compatibility. This value has been lost, apparently, and so nothing in the future will be able to run anything else except modern things.

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

#106

Post by menaerus »

stabbles wrote: post #101
eddd-ddde wrote: post #96

Earlier quoted context omitted.

The answer is obvious, YES, specify your language version. Every single compiler invocation for production (for example ci builds) should explicitly select a version. Otherwise you are asking for trouble.

Yeah, developers should specify what language and dialect a project is written in. In practice though, support for that in build systems is cumbersome. For example in CMake the natural variable is CMAKE_CXX_STANDARD, but it's implemented backwards: if you set it to 14 but your compiler supports only C++11, they'll add -std=gnu++11. You have to also set CMAKE_CXX_STANDARD_REQUIRED to ON, which not man projects do. I d…

There is - you simply build your code with -std=c++XY, and if your toolchain doesn't support it (which one btw doesn't support at least c++17?), it will simply error out, no? That should be a pretty strong signal that your code requires XY standard without having to go into the CMake territory. Even if you want to, I see nothing wrong with the way they are implemented. Two simple variables doing two simple things.

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

#107

Post by menaerus »

ajross wrote: post #33
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.

> What is the downside of switching to the newest standard when it's properly supported? Backwards compatibility. Not all legal old syntax is necessarily legal new syntax[1], so there is the possibility that perfectly valid C++11 code exists in the wild that won't build with a new gcc. [1] The big one is obviously new keywords[2]. In older C++, it's legal to have a variable named "requires" or "consteval", and now it…

> C++ makes breaking changes all the time,

Please don't spread misinformation. Breaking changes are actually almost inexistent with C++. The last one was with the COW std::string and std::list ~15 years ago with the big and major switch from C++03 to C++11. And heck, even then GCC wouldn't let your code break because it supported dual ABIs - you could mix C++03 and C++11 code and link them together.

So C++ actually tries really hard _not_ to break your code, and that is the philosophy behind a language adhering to something that is called backwards-compatibility, you know? Something many, such as Google, were opposing to and left the committee/language for that reason. I thank the C++ language for that.

Introducing new features or new keywords or making stricter implementation of existing ones, such as narrowing integral conversions, is not a breaking change.

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

#108

Post by cemdervis »

tlb wrote: post #79
jcelerier wrote: post #75

Earlier quoted context omitted.

Where do you draw the line for properly supported? I've been using g++ in c++23 mode for quite some time now - even if every feature is not entirely implemented, the ones that work, work well and are a huge improvement

I draw the line where I can't expect the default gcc on most Linux and Mac systems to compile my code. And I don't want to force them to install a particular compiler. -std=c++20 seems to work pretty reliably these days. We're starting to need caniuse.com for C++.

https://cppstat.dev

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

#109

Post by tlb »

cemdervis wrote: post #108
tlb wrote: post #79

Earlier quoted context omitted.

I draw the line where I can't expect the default gcc on most Linux and Mac systems to compile my code. And I don't want to force them to install a particular compiler. -std=c++20 seems to work pretty reliably these days. We're starting to need caniuse.com for C++.

https://cppstat.dev

Aha, that's just what I wanted!

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

#110

Post by ajross »

menaerus wrote: post #107
ajross wrote: post #33

Earlier quoted context omitted.

> What is the downside of switching to the newest standard when it's properly supported? Backwards compatibility. Not all legal old syntax is necessarily legal new syntax[1], so there is the possibility that perfectly valid C++11 code exists in the wild that won't build with a new gcc. [1] The big one is obviously new keywords[2]. In older C++, it's legal to have a variable named "requires" or "consteval", and now it…

> C++ makes breaking changes all the time, Please don't spread misinformation. Breaking changes are actually almost inexistent with C++. The last one was with the COW std::string and std::list ~15 years ago with the big and major switch from C++03 to C++11. And heck, even then GCC wouldn't let your code break because it supported dual ABIs - you could mix C++03 and C++11 code and link them together. So C++ actually t…

> Introducing [...] new keywords [...] is not a breaking change.

This is some kind of semantic prestidigitation around a definition for "breaking" that I'm not following. Yes, obviously it is. New keywords were valid symbol names before they were keywords.

Makes me wonder if the "don't spread misinformation" quip was made in good faith.

Post reply on HN