[boost] More refinement for future(?) more_io

From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-06-10 13:46:08

Since my last announcement (a couple of weeks ago) of refining the 
more_io files that were reviewed a few months ago, I've done another 
set of revisions.  The altered files are in the Boost Sandbox CVS.

Besides an altered "boost/io_fwd.hpp" and "libs/io/doc/index.html", we 
got:
        boost/io/array_stream.hpp
        boost/io/iomanip.hpp
        boost/io/streambuf_wrapping.hpp
        libs/io/doc/array_stream.html
        libs/io/doc/iomanip.html
        libs/io/doc/streambuf_wrapping.html
        libs/io/test/array_stream_test.cpp
        libs/io/test/iomanip_test.cpp

Changes:
* changed the test files to use Boost.Test's unit test system
* a few documentation tweaks, and documentation of the following code 
changes
* compacted some more repeating templates with macros
* added missing stream(buf) typedef's
* for array-based stream buffers, added accessors for the read and 
write character counts/positions
* for array-based stream buffers, clarified copy constructor semantics 
(but blocked the standard assignment operator)
* for array-based streams and stream buffers, added ability to specify 
the opening mode on construction; for stream buffers, added an 
inspection method for the opening mode
* for array-based stream buffers, enabled buffer positioning (by giving 
new meaning to the seekoff and seekpos virtual methods); this allows 
the positioning methods given in the input and output stream base 
classes to work

Some questions/RFCs:

1.	The observer methods "characters_read" and "characters_written" 
return zero if the current get/put area is at the beginning of the 
internal array, or if that particular area is inactive (via not 
activating its bit in the constructing opening mode).  Should I change 
the semantics to return (-1) if that particular area is inactive, so 
the two cases can be distinguished?
2.	If the change proposed in [1] is done, should I remove the opening 
mode observer method "open_mode"?  If I do [1], then I can calculate 
the mode manually by testing the results of "characters_read" and 
"characters_written".
3.	The buffer positioning overrides were written after 
"characters_read" and "characters_written".  Since the repositioning 
methods can indirectly give the position of an area marker, they 
overlap in functionality with "characters_read" and 
"characters_written".  Should I just remove my custom methods?  Note 
that answering "yes" will affect [1] and [2].

Daryle