From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2003-03-11 18:50:07
Having implemented [most of] the IOStreams library I think I can comment
on the array streams stuff:
- Stream buffers normally cannot be copied and I don't see any reason
why this should be different for array streams. The only good this
copy constructor would is to allow returning this kind of stream
buffer from a function and I cannot see any argument in favour of
this... (if there are good arguments for this, they are lacking from
- I could imagine that constructor taking a sequence as argument could
be put to good use: Essentially, I cannot see any approach to
preinitialize the internal array for some output and I would prefer
this approach over the non-const iterators to initialize the get area.
- The class is definitely lacking access to the end of the put area:
there is no way to tell how many characters were written to the put
area, rendering the class pretty useless for certain applications I
have in mind for it (like, eg. converting some object to a string).
Similiarily, it is assumed that the get area is made up of the whole
array which is also a serious restriction: it is more likely that eg.
a character sequence representing an object only fills a portion of
- As is, the class support both input and output at the same time. This
seems to indicate that the last get position should be coupled with
the last position it was written to. Alternatively, the object could
be constructed taking an std::ios_base::openmode parameter as
argument to setup only the corresponding buffers. I don't really like
the idea of having a read/write array where there is no control which
characters are initialized and which are not when reading.
- For the "basic_wrapping_ios<...>" the "base_from_member<Streambuf>"
base object should probably be virtual: the way it is, the basic_ios
is still initialized prior to the stream buffer. The intention of
factoring the stream buffer into a base class is, however, to
initialize it prior the ios subobject which is a virtual base of the
stream objects and thus initialized prior to all non-virtual bases.
I think it is reasonable to incorporate a stream buffer like this into
the Boost library. However, I have the feeling that the current proposal
actually has some serious flaws. That is, I would be in favour of the
library if the points I made above are addressed (where addressing
either means changing the details into the mentioned direction or
providing a sound rationale why it should stay the way it is).
I read the documentation of the and the sources of the arary_stream
classes but haven't tried to use or run the code.
-- <mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/> Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk