C++ is unique in that it defines a spec for STL but not implementation. The result is something that is both overspecified and underspecified.
Including batteries is fine. Including a spec for what the batteries should look like is such a profoundly bad idea that no other major language does it.
[–] klempner 4 days ago
[–] forrestthewoods 3 days ago
I think even if C++ had a periodic ABI break that even a better std::regex spec is fundamentally wrong.
As someone who ships cross-platform I never ever want different platforms to have different implementations for things that are not actually platform specific. Having different implementations of std::string depending on if I’m on windows, Linux, Mac, iOS, Android, PlayStation, Xbox, or Nintendo is a profoundly terrible thing to do.
[–] dizzant 4 days ago
C++'s separation of spec from implementation is clearly functional. There are several major open-source standard library implementations that compete on the basis of performance, ABI stability over versions, quality, etc.
C++'s core ethos is "only pay for what you use". std::regex does this. In my experience, the "problem" with std::regex is that it provides more features by default than most people want, and you pay for using those features. Specifically, std::regex respects the runtime locale. There are good reasons a standard library feature might do this (e.g. it simplifies the interface, it's broadly applicable, etc.), but it's obviously not going to give optimal performance. This is a necessary tradeoff for any standard library.
Locale handling requires dynamic memory allocation, virtual function dispatch, sometimes system calls. Locale handling also prevents some low-level optimizations based on the character encoding. If you need that kind of performance, std::regex probably isn't for you, go grab a non-standard library that suits your needs.
[–] forrestthewoods 4 days ago
std::regex is so worthless that no one uses it. My codebase gives CI warnings when it’s used. so it’s not even really a problem. It is indicative of a larger problems.
> C++'s separation of spec from implementation is clearly functional.
Your bar of “clearly functional” is is not a compelling or meaningful bar. What a weird fallacy.
C++11 was pretty great and meaningfully modernized the language. The amount of useful good things in each following release got smaller and smaller. Maybe just one or two useful improvements in C++20. Almost nothing in C++23. And now C++26 has failed to pass. It’s grinding to a halt. The biggest recent features such as concepts and modules have been catastrophic failures.
Those failures aren’t all due to my specific complaint of “battery specs are a bad idea”. But “functional” is the lowest possible bar. And one could argue that as a whole isn’t being met.
[–] ameliaquining 4 days ago
[–] forrestthewoods 4 days ago
There is absolutely no reason for std::deque to be a specification. The committee should either ship a committee library for std::deque or they should leave it to the community. They can provide a battery or they can not. Providing a spec for a battery that is both over and under specified is the absolute worst possible choice.
[–] ameliaquining 4 days ago
[–] tancop 4 days ago
The standard library on the other hand is a library. It's almost always implemented as plain C++ without much platform specific code. ISO could take an existing free licensed implementation and declare it as the standard. Of course anyone is free to make their own competing one, it just has to always match the official library's behavior.
Writing a spec instead of code is just creating duplicate work and compatibility issues any time the spec is unclear.
[–] forrestthewoods 4 days ago
Why on earth would I want a different implementation of std::deque on each platform I use because the compiler team needed to provide one? It’s madness!
[–] imtringued 4 days ago
I remember a language where the core language types, including primitives and a bunch of keywords, were actually defined in the standard library and the compiler just special cased support for the types in the standard library for optimization purposes.
Your loaded question feels very silly from that perspective.
The real problem is the latter: C++ has always had a "you don't pay for what you don't use" as part of its core philosophy but it turns out that doesn't apply if the thing you don't use is ABI stability.
(and, failing an ABI break story, std::regex should have had an implementation that was more PIMPL and less template so it would have fewer ABI issues, possibly followed by a regex2 later that could get more of the compile time bits once implementations were more mature.)