This is what a good system programming standard library should
provide:
1. Types needed to specify library APIs.
2. Functionality for accessing hardware in a non-emulated fashion.
3. Functionality that most _libraries_ need to build on (like
arrays/iterators/ranges).
4. Functionality that is tied to the individual compiler (like
intrinsics).
5. Memory management.
The primary goal of the standard library should not be to support
building applications, but to enable building frameworks and
libraries and the interaction between them.
So if one user says "My app needs to read WAV which is RIFF,
therefore RIFF should be in the standard library" then the
sensible response is: "Do most _libraries_ need RIFF? Why don't
you use the recommended audio library which has optimized WAV
support.".
Surely everyone uses string processing on a daily basis?
No. I personally almost never do string processing in system
level programming languages, what I need is binary serializing
support. Or Collada support. Or audio file format support.
I'd be happy to use a recommended string procesessing library
when or if I need it.
But a standard library MUST have great support for SIMD
intrinsics, i.e. interfacing the hardware, that is much more
critical for system level programming and is tied to the specific
compiler.
