7 ms·

The problem with C++ is not a bad standard library. It’s probably one of the best algorithms and containers libraries in any language.

112233 1y ago
What are you comparing it to? Because wow.
- monkeyelite 1y ago
  Same question for you.
  - 112233 1y ago
    Every time I have to work with text in C++ using stl feels like pulling teeth. It has gotten better over years, but even php gives one stdlib envy. The idea to base everything on iterators instead of ranges, blowing up the code (and amount of errors) — it would have made sense for pure algorithms, but stl insists on having ownership of object placed in the containers. No sane way to work with binary data. Inconsistent allocation and exception ideology through the years. Mysteriously missing functionality. What little ruby, python, php I have written — nothing has felt as clunky as STL. E.g. vector has no "sort" member function. What great benefit not adding it for convenience has brought?
platinumrad 1y ago
<algorithm> is a very good header, but most of the containers are substandard at best. `std::unordered_map` is required to be node-based, `std::map` can't be a B-tree, MSVC's implementation of `std::deque` is infamously a glorified `std::list`, and so on. Pretty much everything else (e.g. iostreams) is horrible.
- TuxSH 1y ago
  Don't forget <tuple> not mandated to be trivial when it can be (and in fact never being trivial with GCC's stdlib), std::print performance issues (see P3107R5, P3235R3), etc. Heck, even std::atomic was designed with only x64 in mind (it clearly shows), and is unusable outside it. One is incentivized to write their own "atomic" class until P3330R0 is approved for RMW-centric platforms ISAs like Aarch32 and Aarch64. And of course, Rust already has "fetch_update"...
  - spacechild1 1y ago
    > Heck, even std::atomic was designed with only x64 in mind (it clearly shows), It certainly wasn't. > and is unusable outside it Total hyperbole. It's perfectly usable on ARM and other platforms. P3330R0 looks a nice addition, though.
    - TuxSH 1y ago
      > It certainly wasn't. The idiomatic way to do RMW (outside simple stuff like fetch-increment) with std::atomic maps 1:1 with x64 assembly and since fetch_update isn't provided, it's the only way to do it. It's way too close for comfort. See [1] for a comparison > Total hyperbole. It's perfectly usable on ARM and other platforms. It's not hyperbole. std::atomic is portable, but that's all it is. std::atomic is about 30% to 40% (with outlined atomics on, which is the default) slower than handrolled asm (or custom reimplementations that provide fetch_update -- same thing). See [2] for a benchmark. [1] https://godbolt.org/z/EasxahTMP https://godbolt.org/z/EasxahTMP [2] https://godbolt.org/z/Y9jvWbbWf https://godbolt.org/z/Y9jvWbbWf
      - spacechild1 1y ago
        Yes, the design of std::atomic probably favors x64 in certain areas. However, you initially claimed that std::atomic has been designed with only x64 in mind. This is simply not true, which is easily proven by the fact that they explicitly support weak memory models. > std::atomic is about 30% to 40% (with outlined atomics on, which is the default) slower than handrolled asm Only for certain CAS operations. A 30% or 40% performance penalty doesn't sound too dramatic and certainly makes it "usable" in my book. I appreciate your insight, but it could have been delivered with less hyperbole.
- monkeyelite 1y ago
  I agree with that. But which language has better containers?
  - platinumrad 1y ago
    Boring answer, but Rust has better containers (and worse algorithms).
    - tialaramex 1y ago
      Neither can be compared cleanly because the languages make such different choices but it's certainly true that C++ has too many garbage "never use this" container types in the standard library. Aria has a brief aside in her "Entirely Too Many Linked Lists" tutorial about why Rust has so few containers in the stdlib (Aria weeded out all the niche container types before Rust 1.0), and it sincerely feels as though 1995 era C++ could have done with an Aria.
  - colejohnson66 1y ago
    dotnet/C#?
Const-me 1y ago
> probably one of the best algorithms and containers libraries in any language Mostly agree about the algorithms. Another good thing in C++ are low-level mathematic parts of the standard library in <cmath> and <complex>. Containers are OK, but neither usability nor performance are IMO great. Node-based containers like red-black trees and hash maps come with a contract which says pointers are stable, by default this means one malloc() per element, this is slow. However, there’re large areas where C++ standard library is lacking. File I/O is questionable to say the least. Networking support is missing. Unicode support is missing, <codecvt> deprecated in C++17 because they found out it no longer implements current Unicode standard and instead of fixing the standard library they dropped the support. Date and calendars support only arrived in C++/20. No built-in way to represent money amount, e.g. C# standard library has fixed-size 16 bytes type for decimal floating-point numbers, Java standard library has arbitrary-precision integers and decimals.
- account42 1y ago
  Unicode is a moving target and not something that can be supported in a standard library that cares about long-term backwards compatibility. Every language that has added native Unicode support has suffered for it. Fixed point types would be nice but can be implemented on your own and integers representing sufficiently small denominations (cents or fractions thereof) work in a pinch to deal with monetary amounts. And for the interface between libraries you will need to deal with things like currencies anyway and that goes well past the scope of a standard library. Networking is also not something that is all that stable on the OS level beyond the basic socks API and you can just use that from C++ if you want to. There is no benefit from cloning the API into the C++ standard. Same for filesystems - operating systems are different enough here that applications are better off handling the differences directly as can be seen in the unsatisfying attempt to abstract them in std::filesystem. Pushing every functionality you can think of into the standard library is a mistake IMO. It should be reserved for truly ossified OS interfaces, basic vocabulary types and generic algorithms. Everything else is bloat that will be obsolete anyway sooner rather than later.
  - Const-me 1y ago
simonask 1y ago
The problem with C++ is not _just_ a bad standard library, but it's also that. There's a lot of "don't use this", including iostreams, std::regex, std::unordered_map, std::variant, and more. Not to mention vestigial parts of failed designs, like std::initializer_list. Every serious C++ project worth its salt includes additional dependencies to patch it up, and it looks like that will be the case in perpetuity, because these problems are unfixable in the holy name of ABI stability. Don't get me wrong, ABI stability is a worthy goal. The committee should just have realized that the current approach to it is untenable. The result is a very half-baked situation where ABI stability is not technically guaranteed, but nothing can be fixed because of it. What a mess. Rust takes a much, much more cautious approach (because of C++'s history), including explicitly not supporting Rust-native ABI stability and flat out discouraging dynamic linking. Also not very great, but it's sensible as long as there are no clearly superior solutions.
- account42 1y ago
  > The problem with C++ is not _just_ a bad standard library, but it's also that. There's a lot of "don't use this", including iostreams, std::regex, std::unordered_map, std::variant, and more. Not to mention vestigial parts of failed designs, like std::initializer_list. Those are the result of a constant stream of people complaining that the C++ standard library is bad because it doesn't contain their pet feature. Needing additional dependencies beyond the standard library is not problem but how things should work. Because requirements differ and one persons useful dependency is another persons vestigial bloat.
  - simonask 1y ago
    You’re not wrong in principle, but I think it is absolutely fair to expect a standard library to include a good hash map implementation. These aren’t unreasonable demands. The problem here isn’t that it’s bloated (I don’t particularly think it is), but that the things it provides are often very far from best in class.
    - account42 1y ago

112233 1y ago

What are you comparing it to? Because wow.

monkeyelite 1y ago
Same question for you.
- 112233 1y ago
  Every time I have to work with text in C++ using stl feels like pulling teeth. It has gotten better over years, but even php gives one stdlib envy. The idea to base everything on iterators instead of ranges, blowing up the code (and amount of errors) — it would have made sense for pure algorithms, but stl insists on having ownership of object placed in the containers. No sane way to work with binary data. Inconsistent allocation and exception ideology through the years. Mysteriously missing functionality. What little ruby, python, php I have written — nothing has felt as clunky as STL. E.g. vector has no "sort" member function. What great benefit not adding it for convenience has brought?

platinumrad 1y ago

<algorithm> is a very good header, but most of the containers are substandard at best. `std::unordered_map` is required to be node-based, `std::map` can't be a B-tree, MSVC's implementation of `std::deque` is infamously a glorified `std::list`, and so on. Pretty much everything else (e.g. iostreams) is horrible.

TuxSH 1y ago
Don't forget <tuple> not mandated to be trivial when it can be (and in fact never being trivial with GCC's stdlib), std::print performance issues (see P3107R5, P3235R3), etc. Heck, even std::atomic was designed with only x64 in mind (it clearly shows), and is unusable outside it. One is incentivized to write their own "atomic" class until P3330R0 is approved for RMW-centric platforms ISAs like Aarch32 and Aarch64. And of course, Rust already has "fetch_update"...
- spacechild1 1y ago
  > Heck, even std::atomic was designed with only x64 in mind (it clearly shows), It certainly wasn't. > and is unusable outside it Total hyperbole. It's perfectly usable on ARM and other platforms. P3330R0 looks a nice addition, though.
  - TuxSH 1y ago
    > It certainly wasn't. The idiomatic way to do RMW (outside simple stuff like fetch-increment) with std::atomic maps 1:1 with x64 assembly and since fetch_update isn't provided, it's the only way to do it. It's way too close for comfort. See [1] for a comparison > Total hyperbole. It's perfectly usable on ARM and other platforms. It's not hyperbole. std::atomic is portable, but that's all it is. std::atomic is about 30% to 40% (with outlined atomics on, which is the default) slower than handrolled asm (or custom reimplementations that provide fetch_update -- same thing). See [2] for a benchmark. [1] https://godbolt.org/z/EasxahTMP https://godbolt.org/z/EasxahTMP [2] https://godbolt.org/z/Y9jvWbbWf https://godbolt.org/z/Y9jvWbbWf
    - spacechild1 1y ago
      Yes, the design of std::atomic probably favors x64 in certain areas. However, you initially claimed that std::atomic has been designed with only x64 in mind. This is simply not true, which is easily proven by the fact that they explicitly support weak memory models. > std::atomic is about 30% to 40% (with outlined atomics on, which is the default) slower than handrolled asm Only for certain CAS operations. A 30% or 40% performance penalty doesn't sound too dramatic and certainly makes it "usable" in my book. I appreciate your insight, but it could have been delivered with less hyperbole.
monkeyelite 1y ago
I agree with that. But which language has better containers?
- platinumrad 1y ago
  Boring answer, but Rust has better containers (and worse algorithms).
  - tialaramex 1y ago
    Neither can be compared cleanly because the languages make such different choices but it's certainly true that C++ has too many garbage "never use this" container types in the standard library. Aria has a brief aside in her "Entirely Too Many Linked Lists" tutorial about why Rust has so few containers in the stdlib (Aria weeded out all the niche container types before Rust 1.0), and it sincerely feels as though 1995 era C++ could have done with an Aria.
- colejohnson66 1y ago
  dotnet/C#?

Const-me 1y ago

> probably one of the best algorithms and containers libraries in any language Mostly agree about the algorithms. Another good thing in C++ are low-level mathematic parts of the standard library in <cmath> and <complex>. Containers are OK, but neither usability nor performance are IMO great. Node-based containers like red-black trees and hash maps come with a contract which says pointers are stable, by default this means one malloc() per element, this is slow. However, there’re large areas where C++ standard library is lacking. File I/O is questionable to say the least. Networking support is missing. Unicode support is missing, <codecvt> deprecated in C++17 because they found out it no longer implements current Unicode standard and instead of fixing the standard library they dropped the support. Date and calendars support only arrived in C++/20. No built-in way to represent money amount, e.g. C# standard library has fixed-size 16 bytes type for decimal floating-point numbers, Java standard library has arbitrary-precision integers and decimals.

account42 1y ago
Unicode is a moving target and not something that can be supported in a standard library that cares about long-term backwards compatibility. Every language that has added native Unicode support has suffered for it. Fixed point types would be nice but can be implemented on your own and integers representing sufficiently small denominations (cents or fractions thereof) work in a pinch to deal with monetary amounts. And for the interface between libraries you will need to deal with things like currencies anyway and that goes well past the scope of a standard library. Networking is also not something that is all that stable on the OS level beyond the basic socks API and you can just use that from C++ if you want to. There is no benefit from cloning the API into the C++ standard. Same for filesystems - operating systems are different enough here that applications are better off handling the differences directly as can be seen in the unsatisfying attempt to abstract them in std::filesystem. Pushing every functionality you can think of into the standard library is a mistake IMO. It should be reserved for truly ossified OS interfaces, basic vocabulary types and generic algorithms. Everything else is bloat that will be obsolete anyway sooner rather than later.
- Const-me 1y ago

simonask 1y ago

The problem with C++ is not _just_ a bad standard library, but it's also that. There's a lot of "don't use this", including iostreams, std::regex, std::unordered_map, std::variant, and more. Not to mention vestigial parts of failed designs, like std::initializer_list. Every serious C++ project worth its salt includes additional dependencies to patch it up, and it looks like that will be the case in perpetuity, because these problems are unfixable in the holy name of ABI stability. Don't get me wrong, ABI stability is a worthy goal. The committee should just have realized that the current approach to it is untenable. The result is a very half-baked situation where ABI stability is not technically guaranteed, but nothing can be fixed because of it. What a mess. Rust takes a much, much more cautious approach (because of C++'s history), including explicitly not supporting Rust-native ABI stability and flat out discouraging dynamic linking. Also not very great, but it's sensible as long as there are no clearly superior solutions.

account42 1y ago
> The problem with C++ is not _just_ a bad standard library, but it's also that. There's a lot of "don't use this", including iostreams, std::regex, std::unordered_map, std::variant, and more. Not to mention vestigial parts of failed designs, like std::initializer_list. Those are the result of a constant stream of people complaining that the C++ standard library is bad because it doesn't contain their pet feature. Needing additional dependencies beyond the standard library is not problem but how things should work. Because requirements differ and one persons useful dependency is another persons vestigial bloat.
- simonask 1y ago
  You’re not wrong in principle, but I think it is absolutely fair to expect a standard library to include a good hash map implementation. These aren’t unreasonable demands. The problem here isn’t that it’s bloated (I don’t particularly think it is), but that the things it provides are often very far from best in class.
  - account42 1y ago