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 want to prep for the next stable version. It's reasonable that for the next release you'd bootstrap with the prior releases toolset. That allows you to have a stable starting point.
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 in a future feature.
It is "doable" but why would you do it when you can simply keep the compiler targeting 11 and let it do the code review for you.
Compilers often allow things in 11 that technically are not there until some later standard. Or sometimes things they have always allowed finally got standardized in a later version. Setting your standard to 11 if that is what you want to target it a good first step but don't depend on it - the real tests is all the compilers you care to support compile your code.
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.
> ... 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.
> 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.
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".
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.
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.
The way I read withzombies's comment (and it could be wrong) was they were talking about the language version of the compilers source. I assumed that from the "dogfooding" portion of the comment.
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.
Counterpoint: you could write a C++ compiler in a non-C/C++ language such that the compiler’s implementation language doesn’t even have the notion of C++20.
A compiler is perfectly capable of compiling programs which use features that its own source does not.
This particular compiler does require bootstrapping, and that's obviously what "the compiler" is referring to in that comment.
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.
> This particular compiler does require bootstrapping, and that's obviously what "the compiler" is referring to in that comment.
You have to pick an option: either it requires bootstrapping, or it doesn’t.
As it’s possible to write the C++20 compiler features in C++11 (or whatever GCC or Clang are written in these days), it factually does not require bootstrapping.
This is going in circles and this is my last comment on it, but here is what I originally replied to:
> 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.
…as though building the new version of the compiler depended on the features it’s implementing already existing. This is clearly not the case.
The sentence you've quoted is explaining why a new version of the compiler cannot depend on the new features it's implementing. I.e. the first gcc version that supports C++20 cannot be written in C++20.
Which, as you say, is clearly not the case.
I have no idea how you managed to misread the comment so badly, but there we are.
You're hallucinating a non-existent premise to the actual conversation that occurred.
The person you responded to answered the question posed by the person that they responded to. And they answered it correctly. Your "counterpoints" are counterpoints to an imaginary argument/claim that no one has actually made. The reason why it's not part of the quote that you pulled out of the other comment is that there's no way to quote the other person saying what you're trying to frame them as having said, because it's not what they were saying. This entire subthread is the result of an unnecessary attempt at a correction that doesn't manage to correct anyone about anything.
> My original point is that you can write a compiler for any language in any language.
A perfectly fine observation on its own—but it's not on its own. It's situated in a conversational context. And the observation is in no way a counterpoint to the person you posted your ostensible reply to.
Aside from that, you keep saying "bootstrapping" as in whether or not this or that compiler implementation strategy "requires bootstrapping". But writing a compiler in different source language than the target language it's intended to compile and using that to build the final compiler doesn't eliminate bootstrapping. The compiler in that other language is just part of the bootstrapping process.
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 want to prep for the next stable version. It's reasonable that for the next release you'd bootstrap with the prior releases toolset. That allows you to have a stable starting point.