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

111–119 of 119 posts

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

#111

Post by CyberDildonics »

Maxatar wrote: post #95
suby wrote: post #46

Earlier quoted context omitted.

This is from 2019, prior to the finalization of modules in the standard. I'd be interested in how many of these issues were unaddressed in the final version shipped.

There isn't much of a final version shipped. It's pretty well understood that modules are underspecified and their implementation across MSVC, clang, and GCC is mostly just ad-hoc based on an informal understanding among the people involved in their implementation. Even ignoring the usual complexity and ambiguity of the C++ standard, modules are on a whole different level in terms of lacking a suitable formal specifi…

You should get in there and put all your expertise to work.

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

#113

Post by menaerus »

ajross wrote: post #110
menaerus wrote: post #107

Earlier quoted context omitted.

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

It was. And no, breaking change is not what you seem to imply it is. When talking about breaking changes, introducing new keywords is not what people usually think of. It's irrelevant.

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

#114

Post by ajross »

menaerus wrote: post #113
ajross wrote: post #110

Earlier quoted context omitted.

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

It was. And no, breaking change is not what you seem to imply it is. When talking about breaking changes, introducing new keywords is not what people usually think of. It's irrelevant.

Sigh. "Irrelevant" except in the sense that the code used to build and now it doesn't after a gcc upgrade, you mean. This is an attitude shared (c.f. "greenfield" comments elsewhere in this tree) among a bunch of people who do intensive development and maintenance on active products all the time.

That use case is probably less than 20% of all the C++ development cycles out there. This is a 40 year old language that the bulk of the industry has decided to abandon for new work. The large majority of people doing work on this code are doing minimal-change updates, and nonsense like this is how you end up with rules like "We have to deploy on Ubuntu 20.04 still because the AbandonWare 4.7 library doesn't work on later version".

And it's avoidable, but not if you run around lying to people and yourself about what a breaking change is. Again, look at how C does this. The C standard writers actually know that they're updating a legacy environment and care deeply about full backwards compatibility.

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

#115

Post by Maxatar »

CyberDildonics wrote: post #111
Maxatar wrote: post #95

Earlier quoted context omitted.

There isn't much of a final version shipped. It's pretty well understood that modules are underspecified and their implementation across MSVC, clang, and GCC is mostly just ad-hoc based on an informal understanding among the people involved in their implementation. Even ignoring the usual complexity and ambiguity of the C++ standard, modules are on a whole different level in terms of lacking a suitable formal specifi…

You should get in there and put all your expertise to work.

I did prior to 2017. I realized the committee was 75% politics and people with a lot of time and devotion pushing their pet projects, and about 25% about addressing actual issues faced by professional engineers and decided it was no longer worth the time and effort and money.

The committee is full of very smart and talented people, no dispute about that, but it's also very silo'd where people just work on one particular niche or another based on their personal interests, and then they trade support with each other. In discussions it's almost never the case that features are added with any consideration towards the broader C++ audience.

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

#116

Post by CyberDildonics »

Maxatar wrote: post #115
CyberDildonics wrote: post #111

Earlier quoted context omitted.

You should get in there and put all your expertise to work.

I did prior to 2017. I realized the committee was 75% politics and people with a lot of time and devotion pushing their pet projects, and about 25% about addressing actual issues faced by professional engineers and decided it was no longer worth the time and effort and money. The committee is full of very smart and talented people, no dispute about that, but it's also very silo'd where people just work on one particu…

You implemented modules in 2017 and they didn't use it?

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

#117

Post by menaerus »

ajross wrote: post #114
menaerus wrote: post #113

Earlier quoted context omitted.

It was. And no, breaking change is not what you seem to imply it is. When talking about breaking changes, introducing new keywords is not what people usually think of. It's irrelevant.

Sigh. "Irrelevant" except in the sense that the code used to build and now it doesn't after a gcc upgrade, you mean. This is an attitude shared (c.f. "greenfield" comments elsewhere in this tree) among a bunch of people who do intensive development and maintenance on active products all the time. That use case is probably less than 20% of all the C++ development cycles out there. This is a 40 year old language that t…

Nonsense. Adding more keywords to a language is avoidable? Or making the compiler stricter in checking the integral promotions is avoidable? Sure, it is, but only if you stick compiling all of your code with C89. You're barking at the wrong door.

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

#119

Post by ajross »

menaerus wrote: post #117
ajross wrote: post #114

Earlier quoted context omitted.

Sigh. "Irrelevant" except in the sense that the code used to build and now it doesn't after a gcc upgrade, you mean. This is an attitude shared (c.f. "greenfield" comments elsewhere in this tree) among a bunch of people who do intensive development and maintenance on active products all the time. That use case is probably less than 20% of all the C++ development cycles out there. This is a 40 year old language that t…

Nonsense. Adding more keywords to a language is avoidable? Or making the compiler stricter in checking the integral promotions is avoidable? Sure, it is, but only if you stick compiling all of your code with C89. You're barking at the wrong door.

Adding keywords can be done compatibly. Again, I'm not making things up. A C18 compiler can absolutely build K&R C programs that are probably older than your parents. (C23 did roll back some stuff, to much gnashing of teeth, and seems unlikely to become a default mode for that reason. Most projects are holding at C99/C11.)
Post reply on HN