> 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.
> 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.
That type is not for characters anymore; all these languages treat these values as UTF-16 units. Unlike C++, their standard libraries provide functions to convert strings between UTF-8 and UTF-16, apply Unicode normalization, decode strings into a sequence of code points, etc.
> That's what iostreams are
iostreams tried to implement binary streams, text streams, and object formatting with the same API. Predictably failed all these tasks, the features are too different. A minimalistic C++ API for a stream of bytes might look something like that:
> result in developers making software that doesn't work like users of the OS expect
Can you elaborate? When I write string content = File.ReadAllText( path ) in C#, the standard library does exactly the same thing as some C++ library could do: open file for read access, read it to the end, and because C# strings are UTF-16 convert the bytes from UTF-8 to UTF-16.
> Async interfaces are all the rage these days. Meanwhile browsers have moved from TCP to QUIC
I think both points are exotic stuff. Not sure I would want to see them in C++ standard library. Also going to be hard to design a useful platform-agnostic abstractions. OTOH, Unicode strings, file systems, and streams of bytes are literally everywhere in software.
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.