Mathias Gaunard wrote:
I personally think that there is no use in distinguishing between text and binary I/O. For I/O, you need a binary representation. To get it, you can serialize your object any way you like. This shouldn't be the job of a "binary formatting layer", even though having separate utilities to serialize/unserialize basic types to common representations would be useful (double to Little Endian IEEE 754 Double-precision for example). Also, I believe the narrow/wide characters and locales stuff is broken beyond all repair, so I wouldn't recommend to do anything related to that.
I agree on this. When I heard about iostreams for the very first time I thought: "Wow! C++ even has build-in support for streams, filters, sources and sinks!" I did not want to use std::iostreams for basic io. I thought it'd be a nice thing to build - say - an audio synthesizer on top of. Unfortunately I had to recognize that std::iostreams are about *character* streams and not about streams of arbitrary (user defined) data. Furthermore different concepts (transportation, storage, formatting, ...) are coupled tightly and bound to the domain of character processing in such a way that it was impossible to specialize std::iostreams for my purposes. So, when thinking about the design of an universal IO library I suggest to define a list of operational aspects first and thereby make clear distinction between general stream functionality (transportation, buffering, filtering, ...) and functionality that is specific to character streams (formatting, locals, cin/cout, ...). The latter ('character streams') could then be build on-top of the low level stream functionality ('data streams' or 'object streams'). Think of it as a two-layer OSI model for io. ;) just my 0.02€ cheers sascha