Re: [boost] [rfc] I/O Library Design

From: Sascha Seewald (vudu_at_[hidden])
Date: 2007-06-18 05:07:03

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