3 ms·

...which has been surpassed by two ISO standards already, with the third one on the road.

lichtenberger 3y ago
At least they are already discussing the next version.
ska 3y ago
That’s not really a big deal in this context. Getting over the 2011 change was a big jump, and basically makes modern c++ usable for many more projects. Lots of toolchains are pretty conservative also, 2017 is pretty new there. And much like the ISO standard, updates should be a lot easier now.
pjmlp 3y ago
You will hardly find a C++ compiler that is 100% C++17 compliant, lesser so with those later standards. Currently all C++ implementations are lagging behind ISO, as all major commercial contributors focus in other stacks, and take C++14 / C++17 as good enough for their in-house use of C++. The bigger three have lost steam, while everyone else is even further behind .
- tambre 3y ago
  Is there anything that GCC is missing? Looks complete to me [0]. Everything besides modules is also there for C++20 [1]. I'm at an automotive startup and we've been using a few C++26 features since summer already. [0] https://en.cppreference.com/w/cpp/compiler_support/17 https://en.cppreference.com/w/cpp/compiler_support/17 [0] https://en.cppreference.com/w/cpp/compiler_support/20 https://en.cppreference.com/w/cpp/compiler_support/20
  - pjmlp 3y ago
    Last time I tried C++17 parallel STL algorithms, I wasn't so lucky. Then there is the whole issue that many libraries authors cannot set in stone just one compiler / OS.
  - qznc 3y ago
    Are you ISO26262-compliant and your software is ASIL-A or higher? If no, why would you care about MISRA? If yes, how did you qualify a recent GCC? Safety-critical automotive software development depends on tool qualification, which is often a lot of tedious work. There must be a spec, there must be tests, there must be proof that the tests cover the full spec, you must have a process to inform users about bugs. There is no free compiler which provides this.
    - tambre 3y ago
      Not yet compliant, but working on it. There's quite a few ASIL-D components too. We don't use GCC but rather tip-of-the-tree LLVM. Embedded is a completely separate and different mess using whatever the vendor ships for a particular microcontroller. So far our safety guys haven't seen any issues with tool qualification besides requiring everything to be documented and the whole system to be re-tested in case of any tool changes.
- zamadatix 3y ago
  This metric isn't really useful. This disregards any value of say a compiler implementing 99% of all features ever announced, including draft C++26 features, because it's missing a single C++17 feature preventing it from saying it's fully compliant so we shouldn't bother reading about anything but old stuff. The big 3 already support features from C++23 worth learning about https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support Obviously you can't always use that, but most places with a C++ compiler today support at least some useful features past C++17.
  - pjmlp 3y ago
    It is clearly useful, as it makes impossible to write portable code, across compilers and operating systems. This kind of landmines is what keeps many code bases still using C++11 and C89.
    - zamadatix 3y ago
      Your comment seems to have split in two, so I'll respond to this one as it's the longer of the two. I agree it is annoying when compilers don't support the same features but my point is the question isn't whether there is an unimplemented feature from that revision in many compilers it's whether the feature you want to use is commonly supported. As an example, if you want widely implemented features like <=> from C++20 then it doesn't really matter most compiler stdlibs don't support riemann_zeta from C++17. Waiting for them to do so only sets you behind years or decades because you're looking for arbitrary features you'll likely never use to be universally supported too.
  - pjmlp 3y ago
    It is clearly useful, as it makes impossible to write portable code, across compilers and operating systems.
    - bluGill 3y ago
      Most of what is missing is esoteric features that you propable wouldn't use use. So the code is portable anyway
f1shy 3y ago
I don‘t care what the Standard says. I care about what my compiler can do.

At least they are already discussing the next version.

ska 3y ago

That’s not really a big deal in this context. Getting over the 2011 change was a big jump, and basically makes modern c++ usable for many more projects. Lots of toolchains are pretty conservative also, 2017 is pretty new there. And much like the ISO standard, updates should be a lot easier now.

pjmlp 3y ago

You will hardly find a C++ compiler that is 100% C++17 compliant, lesser so with those later standards. Currently all C++ implementations are lagging behind ISO, as all major commercial contributors focus in other stacks, and take C++14 / C++17 as good enough for their in-house use of C++. The bigger three have lost steam, while everyone else is even further behind .

tambre 3y ago
Is there anything that GCC is missing? Looks complete to me [0]. Everything besides modules is also there for C++20 [1]. I'm at an automotive startup and we've been using a few C++26 features since summer already. [0] https://en.cppreference.com/w/cpp/compiler_support/17 https://en.cppreference.com/w/cpp/compiler_support/17 [0] https://en.cppreference.com/w/cpp/compiler_support/20 https://en.cppreference.com/w/cpp/compiler_support/20
- pjmlp 3y ago
  Last time I tried C++17 parallel STL algorithms, I wasn't so lucky. Then there is the whole issue that many libraries authors cannot set in stone just one compiler / OS.
- qznc 3y ago
  Are you ISO26262-compliant and your software is ASIL-A or higher? If no, why would you care about MISRA? If yes, how did you qualify a recent GCC? Safety-critical automotive software development depends on tool qualification, which is often a lot of tedious work. There must be a spec, there must be tests, there must be proof that the tests cover the full spec, you must have a process to inform users about bugs. There is no free compiler which provides this.
  - tambre 3y ago
    Not yet compliant, but working on it. There's quite a few ASIL-D components too. We don't use GCC but rather tip-of-the-tree LLVM. Embedded is a completely separate and different mess using whatever the vendor ships for a particular microcontroller. So far our safety guys haven't seen any issues with tool qualification besides requiring everything to be documented and the whole system to be re-tested in case of any tool changes.
zamadatix 3y ago
This metric isn't really useful. This disregards any value of say a compiler implementing 99% of all features ever announced, including draft C++26 features, because it's missing a single C++17 feature preventing it from saying it's fully compliant so we shouldn't bother reading about anything but old stuff. The big 3 already support features from C++23 worth learning about https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support Obviously you can't always use that, but most places with a C++ compiler today support at least some useful features past C++17.
- pjmlp 3y ago
  It is clearly useful, as it makes impossible to write portable code, across compilers and operating systems. This kind of landmines is what keeps many code bases still using C++11 and C89.
  - zamadatix 3y ago
    Your comment seems to have split in two, so I'll respond to this one as it's the longer of the two. I agree it is annoying when compilers don't support the same features but my point is the question isn't whether there is an unimplemented feature from that revision in many compilers it's whether the feature you want to use is commonly supported. As an example, if you want widely implemented features like <=> from C++20 then it doesn't really matter most compiler stdlibs don't support riemann_zeta from C++17. Waiting for them to do so only sets you behind years or decades because you're looking for arbitrary features you'll likely never use to be universally supported too.
- pjmlp 3y ago
  It is clearly useful, as it makes impossible to write portable code, across compilers and operating systems.
  - bluGill 3y ago
    Most of what is missing is esoteric features that you propable wouldn't use use. So the code is portable anyway

f1shy 3y ago

I don‘t care what the Standard says. I care about what my compiler can do.