4 ms·

> 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 mathe

> 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
  > not something that can be supported in a standard library that cares about long-term backwards compatibility Standard libraries of Java, JavaScript, and C# are counter-examples. > you can just use that from C++ if you want to Technically, C++ standard could feature an abstract interface for a stream of bytes. Would be useful not only for TCP sockets, also for files and pipes. BTW I’ve been programming C++ for living for decades now, and I never saw production code to use C++ <iostream> header. Instead, C++ developers I worked with have been using either <cstdio> or OS-specific APIs. > applications are better off handling the differences directly Many other languages have managed to design high-level platform agnostic abstractions over these things, and implemented them in the standard libraries. > reserved for truly ossified OS interfaces By now this applies to files, file systems, pipes, and TCP sockets. While there’re some features hard to abstract away (examples include controlling file permissions, and probably asynchronous I/O), many real-world applications don’t need them. They just need basic stuff like read and write bytes from binary streams, concatenate paths, create/open/delete files, listen and accept TCP sockets.
  - account42 1y ago
    > Standard libraries of Java, JavaScript, and C# are counter-examples. You mean because of the 16-bit character type baked into the language even though Unicode has moved past that? > Technically, C++ standard could feature an abstract interface for a stream of bytes. That's what iostreams are. Turns out such abstractions come with overhead and other limitations and you need to use OS-specific APIs for even slightly advanced features anyway. > Many other languages have managed to design high-level platform agnostic abstractions over these things, and implemented them in the standard libraries. And these lowest common denominator "abstraction" result in developers making software that doesn't work like users of the OS expect. > By now this applies to files, file systems, pipes, and TCP sockets. Not at all. Async interfaces are all the rage these days. Meanwhile browsers have moved from TCP to QUIC (which is much more than a stream of bytes so would need a completely different abstraction) and it's not unlikely that other applications will want to move to it too. You can make a basic bitch abstraction for these but if everyone that cares about performance needs to fall back to OS-specific interfaces then that doesn't help that much.

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
> not something that can be supported in a standard library that cares about long-term backwards compatibility Standard libraries of Java, JavaScript, and C# are counter-examples. > you can just use that from C++ if you want to Technically, C++ standard could feature an abstract interface for a stream of bytes. Would be useful not only for TCP sockets, also for files and pipes. BTW I’ve been programming C++ for living for decades now, and I never saw production code to use C++ <iostream> header. Instead, C++ developers I worked with have been using either <cstdio> or OS-specific APIs. > applications are better off handling the differences directly Many other languages have managed to design high-level platform agnostic abstractions over these things, and implemented them in the standard libraries. > reserved for truly ossified OS interfaces By now this applies to files, file systems, pipes, and TCP sockets. While there’re some features hard to abstract away (examples include controlling file permissions, and probably asynchronous I/O), many real-world applications don’t need them. They just need basic stuff like read and write bytes from binary streams, concatenate paths, create/open/delete files, listen and accept TCP sockets.
- account42 1y ago
  > Standard libraries of Java, JavaScript, and C# are counter-examples. You mean because of the 16-bit character type baked into the language even though Unicode has moved past that? > Technically, C++ standard could feature an abstract interface for a stream of bytes. That's what iostreams are. Turns out such abstractions come with overhead and other limitations and you need to use OS-specific APIs for even slightly advanced features anyway. > Many other languages have managed to design high-level platform agnostic abstractions over these things, and implemented them in the standard libraries. And these lowest common denominator "abstraction" result in developers making software that doesn't work like users of the OS expect. > By now this applies to files, file systems, pipes, and TCP sockets. Not at all. Async interfaces are all the rage these days. Meanwhile browsers have moved from TCP to QUIC (which is much more than a stream of bytes so would need a completely different abstraction) and it's not unlikely that other applications will want to move to it too. You can make a basic bitch abstraction for these but if everyone that cares about performance needs to fall back to OS-specific interfaces then that doesn't help that much.