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

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2007-06-17 23:00:16

Mathias Gaunard <mathias.gaunard_at_[hidden]> writes:

> Sebastian Redl wrote:
>> Now I have a preliminary design document ready and would like to have
>> some feedback from the Boost community on it.
>> 
>> The document can be found here:
>> http://windmuehlgasse.getdesigned.at/newio/
>> 
>> I'd especially like input on the unresolved issues, but all comments are
>> welcome, even if you tell me that what I'm doing is completely pointless
>> and misguided. (At least I'd know not to waste my time with refining and
>> implementing the design. :-))

> I personally think that there is no use in distinguishing between text 
> and binary I/O.

I think part of the issue may be the name "binary".  A better name may
be "byte" I/O or "byte" stream.  Conceptually it seems important to
distinguish between a byte stream and a character stream.  At the C++ type
level, however, it may indeed not be useful to distinguish between a
"character" stream and a "byte stream", and instead merely allow streams
of any arbitrary POD type.  Then a "byte" stream is defined as a stream
of uint8_t, and a character stream may be a stream of uint8_t or
uint16_t or uint32_t, depending on the character encoding used.

> 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 believe that this library will attempt to address and properly handle
those issues.

> I also think text formatting is a different need than I/O.
> Indeed, it is often needed to generate a formatted string which is then 
> given to a GUI Toolkit or whatever.

Presumably this would be supported by the using the text formatting
layer on top of an output text sink backed by an in-memory buffer.

-- 
Jeremy Maitin-Shepard