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:[EMAIL PROTECTED]> <http://www.dietmar-kuehl.de/> Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
