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:
>> 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
> 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
I believe that this library will attempt to address and properly handle
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk