Corentin Jabot, a C++ standards committee participant, writes about the standard library, ABI stability, safety, and language proposals.
Commenters cite his ABI post as a classic, noting that slow std::regex and other standard library problems stay frozen because of ABI stability.
My problem is that if you're an actual C superset, you're carrying a lot of baggage that will permanently compromise the best case of what you can ever become.
These days, with C standards back on a regular cadence, the thing you have to be a superset of is also a moving target, and you have to make sure your extensions don't end up incompatible with future C changes. If you succeed enough, the C standard has to be worried about compatibility with you in return.
Even the most conservative C supersets like non-standard GNU C have created friction for what the actual ISO standard can do in future, including the highly demanded addition of nested functions [1]. One could almost argue that the long-term value of that C superset will be net-negative precisely because it was successful enough to become a permanent interoperability hazard for C itself. (They could have avoided that by not claiming to be C at build time, but that would have also avoided anyone ever using it, just like almost all of the other supersets).
C++ isn't even a C superset and still that relationship creates friction both ways [2].
Now if you're not a C superset, you have a more difficult adoption story and that is enough to kill a language before it ever has a chance. Even so, far more languages have succeeded by tackling interoperability problems than by being supersets.
Rust has a fair amount of friction binding to C, but people see enough value in overcoming that; and part of what people claim to…
And yet C, an even lower-level language, achieves the same effect without the duplication of PIMPL. You just forward-declare a struct, and declare functions that accept pointers to it: the header doesn't need to contain the struct fields, and you don't need to define any wrapper functions. Technically you can do the same in C++. But in C++ to make an idiomatic API you need methods instead of free functions, and you can't declare methods on forward-declared classes. Why not? Well, I can imagine some reasons… but they have more to do with C++'s idiosyncrasies than any fundamental limitation of a low-level language.
The C++ committee could address this, but instead they seem to want to pretend separate compilation doesn't exist. (Why are there no official headers to forward-declare STL types, except for whatever happens to be in <iosfwd>?) Then they complain about how annoying it is to preserve ABI stability for the standard library, blaming the very concept of a stable ABI [1] [2], all while there are simple language tweaks that could make it infinitely more tractable! But now I'm ranting.
[1] https://cor3ntin.github.io/posts/abi/
[2] https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please
> "how to make STL implementation less embarassing".
The "STL" part of the standard library - containers especially but not just that - has an outdated interface, and suffers from ABI being stuck:
https://cor3ntin.github.io/posts/abi/
so it's embarrassing regardless.
> there still is no language support for e.g. debugging constexpr, or printing internal private state of objects in 3rd party code.
Actually, reflection might make it easier to do that. Supposedly, you should be able to get a member pointer to the private member you're interested in (or even do it dynamically by iterating over all members, and figuring out which one you like), from that and an actual object obtain a regular pointer, and finally dereference it.
As far as I can tell, Priority #1 is backwards compatibility. For example, std::regex can be slower than launching PHP and running the regex there¹, but that won't be fixed because it would require an ABI break. I'm not sure how that happened, as neither the poor performance nor the unwillingness to change ABI were unknown. Performance seems to not have been the top priority in the design of std::unordered_map either, which requires reference stability and therefore boxing. This likewise isn't something unexpected.
¹: https://cor3ntin.github.io/posts/abi/
- a WG paper by a google employee regarding breaking the C++ ABI: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1863r1.pdf
- A post about a C++ ABI break being voted against: https://cor3ntin.github.io/posts/abi/
I would not be surprised if google (or others in favor of breaking the ABI for the c++ standard library) would refocus on their alternate non-std std-replacement-ish library implementations (like abseil) instead given the lack of willingness to fix things in std proper from the committee.
Yeah but ABI stability isn't really just magic dust you sprinkle in you language/compiler and make it more stable
It's a straightjacket that has application in few select cases.
Things ABI prevents in C++:
- better shared_ptr
- adding UTF8 to regex
- int128_t standardisation
- make most of <cstring> constexpr
And so on: https://cor3ntin.github.io/posts/abi/
I get you might have particular criteria on this. But it's a feature that comes with huge, massive downsides.