[boost] I/O library formal review

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
  the rationale).

- 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
  the array.

- 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/>