WG21 ships a completely new language - very similar to but technically unrelated to the previous one - every three years. C++ 11, C++ 14, C++ 17, C++ 20, and (later this year presumably) C++ 23. It is fascinating that people consider the resulting arbitrary source code breaks to be complete compatibility and yet Rust's choice to offer ongoing compatibility to Rust 2015 edition (Rust 1.0) is somehow not enough...
C++ already changed the definition of std::string, that's why your Linux distro went through painful C++ ABI changes many years ago. They went from one terrible string design to a different terrible string design, ruling out some optimisations GNU can chosen, but mandating optimisations other groups had chosen.
Don't worry though, they didn't standardize an actual string slice type (Rust's &str) until much later, as std::string_view in C++ 17, so most software which didn't actually care about string allocation needed to be thrashed around anyway because there was no vocabulary type for this most obvious thing aside from the hopeless C-style "nul terminated char *".
It's actually hard to over-estimate how terrible they are at this (language standardization). Is it really just that there are too many of them? I find it hard to imagine that just large numbers of people can explain it, plenty of people co-operate to create Rust and the results aren't anywhere close to as awful. Maybe it's the ISO process? I have never participated in ISO standardization of something this complicated, maybe the process is somehow poisonous.
But I think the best explanation is the culture. C++ has developed a culture which prizes arcane nonsense.
This includes the committee that makes the standard and requires a working battle tested implementation before inclusion.
So you get a Frankenstein result because that is the input.
And while yes in theory the standards define a kind of C++ that works on every compiler but the reality is most compilers don't fully support that for literal years best case.
So everyone uses what is available and writes abstractions to handle the harsh edges if they support multiple compilers.
> This includes the committee that makes the standard and requires a working battle tested implementation before inclusion.
This "requirement" is a mirage, as you can tell by simply installing any of the three compilers from say the week C++ 20 was published and trying to use the headline "modules" feature described in the standard. There are no working implementations.
If you've worked at a large dysfunctional organisation you'll recognise the pattern. Nobody wants to say "No" and make a decision themselves which may go badly - so instead they look for excuses and you're listing one of the excuses. But when they want to do it none of the excuses apply.
GNU didn't do any optimizations that are acceptable in a language with move semantics. The new `std::string` is _strictly_ better than the old one. Although there do exist very many superior string containers outside of the standard library. libstdc++ still supports the old ABI, by the way, as `std::__cxx11::string`.
Large part of why standard was changed so that GCC's copy-on-write strings became non-standard compliant was because CoW made std::string_view and such extremely hazardous. CoW has its benefits but also huge downsides, and small-string optimisation makes lot more sense with the C++11 move semantics.
For many people SSO would be a waste of time except you need to store the empty string.
There are people who make a lot of very short strings and need them to go fast, but not so many to justify making that a core language feature, if not for the fact that C++ empty string needs a zero byte for C compatibility.
That's why Rust got away without it, their empty string has length zero.
C++ already changed the definition of std::string, that's why your Linux distro went through painful C++ ABI changes many years ago. They went from one terrible string design to a different terrible string design, ruling out some optimisations GNU can chosen, but mandating optimisations other groups had chosen.
Don't worry though, they didn't standardize an actual string slice type (Rust's &str) until much later, as std::string_view in C++ 17, so most software which didn't actually care about string allocation needed to be thrashed around anyway because there was no vocabulary type for this most obvious thing aside from the hopeless C-style "nul terminated char *".
It's actually hard to over-estimate how terrible they are at this (language standardization). Is it really just that there are too many of them? I find it hard to imagine that just large numbers of people can explain it, plenty of people co-operate to create Rust and the results aren't anywhere close to as awful. Maybe it's the ISO process? I have never participated in ISO standardization of something this complicated, maybe the process is somehow poisonous.
But I think the best explanation is the culture. C++ has developed a culture which prizes arcane nonsense.