Source: I've been writing C++ for 8 years.
C++ is not supposed to be fresh. It’s supposed to be portable, and allow fine tuning of programs to bare metal while allowing a sort of high level implementation of API:s (but often fragile and badly designed).
Some new features are excellent, others are not, and the history is plagued with weird historical feature gaps obvious to anyone familiar at all with more consistent languages.
So if something feels weird, there is always a good chance it’s not you, it’s the language (committee).
* Support for multiple, different, programming paradigms.
* Very strong backwards compatibility, all the way back to C.
... then some "freakness" is to be expected. And I do believe some of the additions (to the library and the languages) have been excessive. However, I disagree with your characterization of language development work.
1. Most people on the committee, AFAICT, are from industry rather than academia. And if you consider national bodies, I think the ratio is even higher.
2. "Keeping the language fresh" is not a goal and not what the committee does. Most of what's added to the language are things that people have been complaining about the lack of for _decades_.
3. Feature proponents are those who want to "bolt on new stuff". Committee members are tasked with preventing new stuff being just bolted on.
4. Some new additions are necessary, and others are not necessary but useful, for "tuning programs to bare metal".
Finally - I agree that committee-work has the drawback of less consistency; and there are definitely warts. But for an established language with huge existing codebases and many stake-holders, and with the design goals I mentioned above in mind - an international committee and consensus-building is better than appointing some benevolent dictator.
And are useless now, because everybody who had that problem either already solved it (the solution could have been "use another language") or did realise that it is not worth the hassle. I guess the best examples are `std::format` or `std::thread`.
> But for an established language with huge existing codebases and many stake-holders, and with the design goals I mentioned above in mind - an international committee and consensus-building is better than appointing some benevolent dictator.
That depends, but yes, everything is better than letting Stroustroup "decide".
It might be better if it had a true BDFL, instead of a spiritual guide, and I do worry about the committee getting too far ahead of the industry and leaving it behind, plus what will happen when Stroustrup finally retires in earnest.
But yeah, now and then it does produce a turd, and there’s only so much turd-polishing you can really do.
I guess I’m just saying it’s a development model with pros and cons. The pros are necessary. The associated cons are inevitable.
Everyone has one vote, and everything turns around politics to win mini-elections per feature evolution stage.
[1] https://github.com/google/dawn/blob/40cf7fd7bc06f871fc5e4823...
[2] https://github.com/protocolbuffers/protobuf/blob/c964e143d97...
[3] https://github.com/facebook/react-native/blob/77b3a8bdd6164b...
[4] https://github.com/NVIDIA/cccl/blob/07fef970a33ae120c8ff2a9e...
There is a reason why C++17 is the best we can currently hope for in what concerns portable code, given the actual support across industry compilers, and company project guidelines.
Many embedded shops might still be discussing between adopting C++11 or C++14.
However the adoption rates of newer C++ features are in fact new are way lower. From what I see lots of projects still use the language as C with Classes, basically, and that ain't going to change any time soon. The GP nailed it - C++ is adding a lot of esoteric stuff that very few people actually need or want.
C++20 is still too fresh for my industry, especially for embedded where runtimes require certification for functional safety. Maybe in two years.
What can I tell The Committee? Stop. No, we don't need a single central ex cathedra library for networking. Or graphics. Or SIMD. Even the existing filesystem library is so broken it's dangerous (the standard specifies if it's used on an actual filesystem it's undefined behaviour -- which means using <filesystem> means your program could provoke the legendary nasal daemons just by being run). Stick to generic basics and leave the specialized stuff that not everyone needs to third-party libaries. Nothing wrong with a marketplace of libraries to serve an entire economy of requirements.
> Behavior is undefined if calls to functions provided by subclause [filesystems] introduce a file system race.
~Nobody uses all the recent features, but some new C++20 stuff does get adopted very quickly, like 3-way comparisons, constinit, abbreviated function template, etc.
For C++23, support for it is severely lacking in MSVC at least, so that's going to severely impact users.
There can't be full C++23 support when they are still busy adding C++17 and C++20 features.
It depends what industry you're working on. A lot of HFT shops keep up to date with the latest compiler and make extensive use of new features that improve the ergonomics and compile-time performance of template metaprogramming, which is important for achieving the lowest possible latency.
That's verifiably not true.
https://www.jetbrains.com/lp/devecosystem-2023/cpp/
Anecdotally, all the stuff I do has been minimum C++20 for a few years. If you're using e.g. Qt 6, released in 2020, you're using at least C++17 features without knowing it ; same for recent versions of boost which start depending on C++17 or C++20 depending on the features / libraries.
Some reason I can think of:
- Can't update the compiler (eg, porting the code base to the new compiler is too complicated)
- No compiler support for the new standard that target a specific platform that one still want to support.
- Too much work to update the whole code base to work with the new standard.
- A 3rd party library is not supporting new standard yet.
- The team is reluctant to have to learn new technologies.
Some are somewhat valid reason, some are less, some are indication of deeper problems.
(P.S: My C++ code base is using C++20. Didn't move to C++23 yet because I think some customers might not be ready for it yet for one of these reasons, but I'm going to push for it at some point.)
"One major gripe I have with cars is the number of people that know how to drive one is very close to zero."
Where I work (big tech) everything is c++17. I don't know what the schedule is but in a couple of years every bazel and CMake will get bumped to c++20. And so on.
With Python, there is no standard per se, it is whatever CPython does, and everyone else has to try to mimic CPython.
Most of the new features are for library writers.
From my limited experience - high-quality internal libraries are simply not the reality; less likely to be achieved than winning the lottery. Companies typically:
* are not able to identify candidates able of writing high-quality C++
* do not try to attract SW engineers by committing to high-quality code.
* don't believe they should invest developer time in making a library more robust, and bringing them to the level of polish of a popular publicly-available FOSS libraries.
* do not have a culture of acquiring, honing and sharing coding skills and expertise, with the help of actual experts. Again, time and effort is mostly not invested in this.
Quality gaps like described above - I think this happens when you try to develop C++ without actual experience in C++. C++ is so weird anyone trying to ”do the right thing in the language they are most familiar with” generally get it wrong for the first few years. And then you end up with a quagmire nobody wants to volunteer to clean up.
This is not a skill issue as such or lack of talent. C++ simply is so weird and there is so much bad ”professional advice” that you are expected to loose a few limbs before being able to navigate the design landscape full of mines.
Not only that, but the rookie developers coming in get inculcated into that. That's what they're used to, and they have all the motivation to continue writing poor code, because they need to avoid their better code clashing with what's already written - clashing compilation-wise and style-wise.
Of course, it's not 100% all bad, there are gradual improvements in some aspects by some developers.