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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk