71–80 of 119 posts
Earlier quoted context omitted.
That's not a counterpoint—at least not to anything in the comment that you're (nominally) "responding" to. So why has it been posted it as a reply, and why label it a counterpoint?
Read them again a couple more times and it may become clear. The prior post seemed to be claiming that this required any form of a bootstrapping process, when it does not.
Earlier quoted context omitted.
This is not the case. They are discussing the default value of `g++ -std=...`. That does not complicate bootstrapping as long as the C++ sources of GCC are compatible with older and newer versions of the C++ standard.
> 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…
Even if you only target 11, there may be advantages to setting a newer version anyway. Sometimes the standard finally allows some optimization that would work, or disallows something that was always error prone anyway. I would recommend you set your standard to the latest the compiler supports and fix any bugs. Solve your we have to support older standards problem by having your CI system build with an older compiler (and also the newest one). C++ is very good at compatibility so this will rarely be a problem.
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.
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…
well, shouldn't not-up-to-date code use the corresponding compiler flag instead of someone starting a greenfield project, who might then write outdated code?
Like, think about it: if you think the defaults should be good for greenfield projects, then greenfield projects won't be using the correct flags (because if they are, then the whole argument is specious anyway). And when C++34 shows up, they're going to be broken and we'll have this argument again.
Compatibility is hard. But IMHO C++ and gcc are doing this wrong and C is doing it much better.
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? "Properly supported" is the key here. Does GCC currently properly support C++23, for example? When I checked a few months ago, it didn't.
Good. Let me use modules!
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.
Warnings becoming errors would be scoped to gcc itself only, and they can fix them as part of the upgrade.
Earlier quoted context omitted.
That's not a counterpoint—at least not to anything in the comment that you're (nominally) "responding" to. So why has it been posted it as a reply, and why label it a counterpoint?
Read them again a couple more times and it may become clear. The prior post seemed to be claiming that this required any form of a bootstrapping process, when it does not.
Building your compiler in another language doesn't help at all. In fact, it just makes it worse. Dogfooding C++20 in your compiler that isn't even built in C++ is obviously impossible.
Earlier quoted context omitted.
> What is the downside of switching to the newest standard when it's properly supported? "Properly supported" is the key here. Does GCC currently properly support C++23, for example? When I checked a few months ago, it didn't.
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
We're starting to need caniuse.com for C++.
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.
C++ is very good at compatibility. If your code breaks when the standard changes, odds are it was always broke and you just didn't know. C++ isn't perfect, but it is very good.