4 ms·

Anyone else getting concerned about the rate of development of the C++ Standard vs compiler implementation? We don't even have feature complete C++20 on the maj

Anyone else getting concerned about the rate of development of the C++ Standard vs compiler implementation? We don't even have feature complete C++20 on the major compilers yet. C++23 is even less implemented. How will the committee handle this? Will they reduce feature additions at some point in the future? https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support

Pet_Ant 1y ago
Maybe knowing where a language is going will help them implement older features? Also, some things are technically easy once all the conceptual wrinkles are ironed out. There is no reason some of these can't be added before C++20 is 100% supported.
- mkoubaa 1y ago
  I can't imagine why someone would care about that, rather than about the specific changes they actually use or want to use.
OneDeuxTriSeiGo 1y ago
It is worth noting that one of the main reasons why C++ standard evolution is faster nowadays is because the "bare minimum" for consideration of acceptance in the standard is working examples on a fully functioned compiler. This tends to make it a lot easier for other compilers to implement those features as there is at minimum a working reference to compare against (vs older still unimplemented features like modules where nobody really ironed out how to properly implement them until after they were shoehorned into the standard)
almostgotcaught 1y ago
the only people that complain about this don't actually write C++
- pjmlp 1y ago
  I write C++, and complain about still not having a portable C++17 implemenation that fully supports parallel STL, not having a full compliant C++20 compiler, embedded compilers kind of still catching up with C++14, and I could rant on.
  - ynik 1y ago
    Are there any embedded compilers left that try to implement their own C++ frontend? To me it looks like everyone gave up on that and uses the clang/gcc/EDG frontends.
    - pjmlp 1y ago
      Yes, and even those that have compiler forks aren't on vLatest. Interesting you mention EDG, as it is now famously know as being the root cause why Visual Studio development experience lags behind cl.exe, pointing out errors that compile just fine, especially if using anything related to C++20 modules. Apparently since the modules support introduced in VS 2019, there have been other priorities on their roadmap.
  - nurettin 1y ago
    Yes to all that, but oneapi::dpl has been out for a while.
    - pjmlp 1y ago
      And how much does that help anyone in systems that can't make use of it?
      - nurettin 1y ago
        As much as C helps on TinyOS with a MICaz board I guess.
        pjmlp 1y ago
whatagreatboy 1y ago
That is more on the fact that less investment is made in C++ compilers nowadays. Companies are migrating away from C++ and it shows in compiler development.
pjmlp 1y ago
Yes, it changed my point of view that it is about time WG21 goes back to the old ways of only standardising existing practice, or at very least proposals without preview implementations shouldn't even get discussed in first place. The problem is that with the new wind C++ got with C++11, its role in GCC and LLVM, and domains like HPC, HFT, GPGPU, WG21 got up to 300 something members, everyone wanting to leave their name on a C++ standard, many proposing features in PDF form only. And since in ISO driven languages, what gets into a standard, does so by votes, not technical implementation merit, it is about doing a proper campaign to get the bases to vote for your feature, while being persistent enough to keep the process going. Some features have more than 20 revisions on their proposal.
- einpoklum 1y ago
  The other side of that coin is that if you required "technical implementation merit", then only people or groups who have strong experience with C++ compilers would be able to propose things. I'm not saying that the existing situation is ideal and it's certainly not a dichotomy, but you have to consider the detriments as well as the benefits.
  - Measter 1y ago
    You could have a two-stage process. Stage 1 would be the proposal, where you have the discussion on whether the feature is desirable or not, which can then be provisionally accepted. At this point it is not in the standard. Then you have Stage 2, which would require an actual working implementation, so it can be properly tested and such. Acceptance in Stage 2 would result in the feature being in the standard.
  - pjmlp 1y ago
    Great, languages like C++ relevance on the industry, should have a "you should be this high to play" entrance price. Also I should add this is no different on wannabe C and C++ replacements, or most other programming languages with similar market share. Go try to do a drive by pull request for a new language feature on those ecosystems.
- zombot 1y ago
dahart 1y ago
FWIW, I can’t ever remember a time when the most widely used compilers in practice weren’t around 5-10 years behind changes in the standard. Part of the issue is that adoption takes time, and always will. A lot of people using C++ professionally don’t want to be on the bleeding edge of language changes. Some do, but a lot don’t, for good reasons. When I was in college in the 90s, templates were new and had iffy support. In the 2000s, STL was still problematic. I remember the Microsoft Compiler spitting out error messages on STL types that were so long the compiler couldn’t handle the string length and truncated the error message so you couldn’t see what the problem was. In the late 00s and early 10s I worked in games, we wanted stability and for the code to be as non-tricky as possible (for example by banning use of exceptions, STL containers, and most casual heap allocation, among other things.) So we used older compilers by choice. My current job publishes an SDK and APIs that people have been using for many years, they need to be backward compatible and we can’t impose recent language features on our users because not everyone uses them, we have to stick to features that compile everywhere, so I still see lots of C++{11,14,17}.
- ratmeadow 1y ago
  Perhaps you are right, and I had rose tinted glasses. I seem to remember C++17 being completed (all major features) around 2018 on at least one or two major compilers. Meanwhile C++20 still doesn't have modules properly implemented, which is such a huge feature IMO that I count it as a major deficit. But maybe C++17 was the exception rather than the rule. I think what annoys me most is when a standard is implemented except for an important feature. E.g. ranges was unusable for ages on Clang. And modules is still not quite there. I want to use the latest standard to get these cool features so I can write code like it's 2025, not 1980. If the biggest features are unimplemented then why upgrade? My concern is the trend continues, and we get cool things like reflection, but it takes 10 years to be implemented properly.
  - throwaway2037 1y ago
    I never used modules, but I heard about them. I just checked the official checklist from Clang, and I see this: https://clang.llvm.org/cxx_status.html#cxx20 https://clang.llvm.org/cxx_status.html#cxx20 Wow, the list of papers for Modules is large. I can understand why it is taking so long to implement. Also, there needs to be "fingers to do the typing". I assume most of the commercial devs (Google, Apple) just don't think modules are important enough. It looks like Concepts also took a very long time to be fully implemented. Hell, that feature was discussed for 10 years (a dream of Bjarne) before approved into a standard... then maybe 5 years to impl!
dataflow 1y ago
Yeah, I've been very worried about this. C++23 is basically unimplemented as far as I'm concerned. Working on C++26 makes no sense to me. They gotta space it out more than 3 years, if nothing else.
einpoklum 1y ago
I cannot believe how, after all these years, we don't even have `restrict` in the language, nor uniform function call syntax (i.e. x.foo(y) being interchangeable with foo(x, y) ); but we do get the ultimate bells-and-whistles in the form of reflection and reflection-based code generation; and the half-baked coroutines mechanism. uniform function call syntax and a `restrict` mechanism have not made it in to the standard after so many years
- srean 1y ago
  You might like D.

Pet_Ant 1y ago

Maybe knowing where a language is going will help them implement older features? Also, some things are technically easy once all the conceptual wrinkles are ironed out. There is no reason some of these can't be added before C++20 is 100% supported.

mkoubaa 1y ago
I can't imagine why someone would care about that, rather than about the specific changes they actually use or want to use.

OneDeuxTriSeiGo 1y ago

It is worth noting that one of the main reasons why C++ standard evolution is faster nowadays is because the "bare minimum" for consideration of acceptance in the standard is working examples on a fully functioned compiler. This tends to make it a lot easier for other compilers to implement those features as there is at minimum a working reference to compare against (vs older still unimplemented features like modules where nobody really ironed out how to properly implement them until after they were shoehorned into the standard)

almostgotcaught 1y ago

the only people that complain about this don't actually write C++

pjmlp 1y ago
I write C++, and complain about still not having a portable C++17 implemenation that fully supports parallel STL, not having a full compliant C++20 compiler, embedded compilers kind of still catching up with C++14, and I could rant on.
- ynik 1y ago
  Are there any embedded compilers left that try to implement their own C++ frontend? To me it looks like everyone gave up on that and uses the clang/gcc/EDG frontends.
  - pjmlp 1y ago
    Yes, and even those that have compiler forks aren't on vLatest. Interesting you mention EDG, as it is now famously know as being the root cause why Visual Studio development experience lags behind cl.exe, pointing out errors that compile just fine, especially if using anything related to C++20 modules. Apparently since the modules support introduced in VS 2019, there have been other priorities on their roadmap.
- nurettin 1y ago
  Yes to all that, but oneapi::dpl has been out for a while.
  - pjmlp 1y ago
    And how much does that help anyone in systems that can't make use of it?
    - nurettin 1y ago
      As much as C helps on TinyOS with a MICaz board I guess.
      - pjmlp 1y ago

whatagreatboy 1y ago

That is more on the fact that less investment is made in C++ compilers nowadays. Companies are migrating away from C++ and it shows in compiler development.

pjmlp 1y ago

Yes, it changed my point of view that it is about time WG21 goes back to the old ways of only standardising existing practice, or at very least proposals without preview implementations shouldn't even get discussed in first place. The problem is that with the new wind C++ got with C++11, its role in GCC and LLVM, and domains like HPC, HFT, GPGPU, WG21 got up to 300 something members, everyone wanting to leave their name on a C++ standard, many proposing features in PDF form only. And since in ISO driven languages, what gets into a standard, does so by votes, not technical implementation merit, it is about doing a proper campaign to get the bases to vote for your feature, while being persistent enough to keep the process going. Some features have more than 20 revisions on their proposal.

einpoklum 1y ago
The other side of that coin is that if you required "technical implementation merit", then only people or groups who have strong experience with C++ compilers would be able to propose things. I'm not saying that the existing situation is ideal and it's certainly not a dichotomy, but you have to consider the detriments as well as the benefits.
- Measter 1y ago
  You could have a two-stage process. Stage 1 would be the proposal, where you have the discussion on whether the feature is desirable or not, which can then be provisionally accepted. At this point it is not in the standard. Then you have Stage 2, which would require an actual working implementation, so it can be properly tested and such. Acceptance in Stage 2 would result in the feature being in the standard.
- pjmlp 1y ago
  Great, languages like C++ relevance on the industry, should have a "you should be this high to play" entrance price. Also I should add this is no different on wannabe C and C++ replacements, or most other programming languages with similar market share. Go try to do a drive by pull request for a new language feature on those ecosystems.
zombot 1y ago

dahart 1y ago

FWIW, I can’t ever remember a time when the most widely used compilers in practice weren’t around 5-10 years behind changes in the standard. Part of the issue is that adoption takes time, and always will. A lot of people using C++ professionally don’t want to be on the bleeding edge of language changes. Some do, but a lot don’t, for good reasons. When I was in college in the 90s, templates were new and had iffy support. In the 2000s, STL was still problematic. I remember the Microsoft Compiler spitting out error messages on STL types that were so long the compiler couldn’t handle the string length and truncated the error message so you couldn’t see what the problem was. In the late 00s and early 10s I worked in games, we wanted stability and for the code to be as non-tricky as possible (for example by banning use of exceptions, STL containers, and most casual heap allocation, among other things.) So we used older compilers by choice. My current job publishes an SDK and APIs that people have been using for many years, they need to be backward compatible and we can’t impose recent language features on our users because not everyone uses them, we have to stick to features that compile everywhere, so I still see lots of C++{11,14,17}.

ratmeadow 1y ago
Perhaps you are right, and I had rose tinted glasses. I seem to remember C++17 being completed (all major features) around 2018 on at least one or two major compilers. Meanwhile C++20 still doesn't have modules properly implemented, which is such a huge feature IMO that I count it as a major deficit. But maybe C++17 was the exception rather than the rule. I think what annoys me most is when a standard is implemented except for an important feature. E.g. ranges was unusable for ages on Clang. And modules is still not quite there. I want to use the latest standard to get these cool features so I can write code like it's 2025, not 1980. If the biggest features are unimplemented then why upgrade? My concern is the trend continues, and we get cool things like reflection, but it takes 10 years to be implemented properly.
- throwaway2037 1y ago
  I never used modules, but I heard about them. I just checked the official checklist from Clang, and I see this: https://clang.llvm.org/cxx_status.html#cxx20 https://clang.llvm.org/cxx_status.html#cxx20 Wow, the list of papers for Modules is large. I can understand why it is taking so long to implement. Also, there needs to be "fingers to do the typing". I assume most of the commercial devs (Google, Apple) just don't think modules are important enough. It looks like Concepts also took a very long time to be fully implemented. Hell, that feature was discussed for 10 years (a dream of Bjarne) before approved into a standard... then maybe 5 years to impl!

dataflow 1y ago

Yeah, I've been very worried about this. C++23 is basically unimplemented as far as I'm concerned. Working on C++26 makes no sense to me. They gotta space it out more than 3 years, if nothing else.

einpoklum 1y ago

I cannot believe how, after all these years, we don't even have `restrict` in the language, nor uniform function call syntax (i.e. x.foo(y) being interchangeable with foo(x, y) ); but we do get the ultimate bells-and-whistles in the form of reflection and reflection-based code generation; and the half-baked coroutines mechanism. uniform function call syntax and a `restrict` mechanism have not made it in to the standard after so many years

srean 1y ago
You might like D.