Boost :

bdawes_at_[hidden]

----
The docs should begin with an "Introduction" paragraph which should include 
a "hello, world" level example.
I found myself reading the header to see exactly what classes were
supplied.  The table isn't horrible, but I'm wondering if others also found 
it a bit unclear as to what exactly is delivered?
Granularity
-----------
The fine granularity of the savers gets in the way for certain
applications.  For example, I've got some code like this:
      //  function reports job statistics
      void my_show_stats()
      {
        cout << ... ; // no problem
        third_party_show_stats(); // alters state of cout:-(
        cout << ... ; // weird things happen
      }
So I'd like to rewrite it like this:
      //  function reports job statistics
      void my_show_stats()
      {
        cout << ... ; // no problem
        {
          boost::io::ios_all_saver ioasvr( cout );  // save all state info
          third_party_show_stats(); // alters state of cout
        }
        cout << ... ; // still no problem
      }
Unless I'misreading the docs, I can't do that with a single saver because
the granularity is so fine.
Instead, I'd have to write up to 11 different savers:
      ios_flags_saver
      ios_precision_saver
      ios_width_saver
      ios_iostate_saver
      ios_exception_saver
      ios_tie_saver
      ios_rdbuf_saver
      ios_fill_saver
      ios_locale_saver
      ios_iword_saver
      ios_pword_saver
It isn't that the current fine granularity is wrong; it is exactly what is
needed for some applications.  But for other applications, additional
superset savers would seem to be useful.  Have you given this any thought?
Namespace and namespace issues
------------------------------
The submission supplies two headers - <boost/io_fwd.hpp> and
<boost/io/iostate.hpp>
The contents of the library are placed in namespace boost::io.
For consistency, shouldn't the forward declaration header be named
<boost/io/iostate_fwd.hpp> and placed in the boost/io subdirectory?
Ed Brey
=======
Library naming:
- Iostate isn't really a suitable name for the library (and hence header
file), since iostate already has a meaning, which is more specific that 
what
you are trying to cover.  (This class saves iostate, plus many other
properties.)  Perhaps stream_state or ios_state would be better.
Documentation:
- Contents of index.html should be merged into iostate.html, since this is
such a small library.  Having the extra level in between the main boost
library page and the actual documentation of the library slows down
browsing.  When the user clicks on iostate from the boost library index
page, the first think that he should see is a brief description and a
"Hello, world" example.
- The fact that the iostate.html header includes any other headers should
not be part of the public interface.  Hence, it would be better to show it
in the documented synopsis.  Part of the problem stems from the fact is 
that
document lists a "header synopsis", which isn't exactly what the reader
needs to know.  The information that should be presented is simply a list 
of
classes are guaranteed by be declared/defined when a header is included.
Wish list:
- A predefined saver that saved all formatting adjustments would be quite
nice.  Specifically, this would combine the savers flags, precision, width,
fill, and locale.
- A manipulator version would be nice.  A sample usage would be:
    cout << save_stream_format << setw(5) << x;
--- end of reviews ---