Boost logo

Boost :

From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2007-06-06 10:34:13

Ares Lagae wrote:
> * classes binary_istringstream, binary_ostringstream and binary_stringstream
> The classes binary_istringstream, binary_ostringstream and
> binary_stringstream allow to read/write to a string that serves as buffer
> for the binary data. (althought a streambuf that writes to
> std::vector<unsigned char> would be more suited).
Indeed, basing this off basic_stringbuf (I suppose this is what you're
doing) is most peculiar for binary data. Is there a specific reason why
you don't want to write a stream buffer backed by a std::vector? These
babies aren't particularly hard to write.
> * << and >> operators for string types
> The stream classes now only support fundamental data types. I am not sure
> how and wether to handle strings. For example, a regular char* string can
> be output as a null terminated array of char's, or as a size and a non
> null-terminated array of char's. Although I prefer the first solution (more
> portable, no problems with the size of the size type in the second
> solution), I am not sure if the library should make such a decision.
I fully agree with this decision. Writing strings is IMO a serialization
issue and should not be part of a low-level binary I/O module.
> * compression
> I am also planning on adding a compressing_streambuf class, that can be used
> in both the IOStreams and the binary_iostreams library.
What kind of compression? Would it depend on external libraries? (zlib,
libbzip2, ...) Is it worth the effort when Boost.IOStreams already
supports compression?
> * design
> I agree with a lot of the comments on design of I/O libraries in the
> previous posts. However, I do not have the time to design and implement an
> improved I/O system for C++,
Would you be willing to help me in doing so?

Sebastian Redl

Boost list run by bdawes at, gregod at, cpdaniel at, john at