Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-13 17:09:37

At 04:35 PM 3/13/2002, Brey, Edward D wrote:

>I'm still waiting for a response to my review of the first
submission. The
>only point of the ones I had put forth that was addressed in this latest
>version was the combined saver, and even there, my suggestion was a bit
>different than that of other reviewers in that it called for only the
>combined formatting state to be saved. Likewise, I haven't heard
>to other reviews' comments, for example, refactoring the help file to put
>"Hello world" at the top.
>Was there perhaps a message(s) that I missed that covers the specific
>bullet points of the various reviews? A search in the group archive
>on the iostate subject brought up no messages with itemized responses.

I sent it to Daryle privately. See below. Probably should have posted it


--- begin ---

... the ones that seem to me to be [particularly] important are:

* Docs comments such as request for simple usage examples, etc.

* The request from two people: "A predefined saver that saved all
formatting adjustments would be quite nice."

* Naming and namespace issues.

Geoff Mountfort

-What is your evaluation of the documentation?
It is too much "how it was done" and not enough user level "how to use".

Gary Powell

Quick Question:
   Why does it save a state_type * const s;
   vs, a state_type & ?
   If there were default constructors, and therefore a need to set a "null"
state I'd understand that, but there aren't.

- Documentation:
   Needs a couple of examples for those less proficient with iostate

- Credits:
   I know that I saw an iostate class on c.l.c.m Do a google search, and
that person(s) as the originator in addition to Daryle Walker.

I did and found this earlier reference

That a
Gregory Bond ITG Australia Ltd, Melbourne,
posted Date: 1998/07/01

That's not to say that Daryle didn't either re-invent the idea, or that
become part and parcel of C++ standard usage, but I think the historical
acknowledgement should exist.

Keith Burton

Question : could / should it offered the ability to set / unset format
flags rather than replace them.

Beman Dawes


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?
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:
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
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 
you are trying to cover.  (This class saves iostate, plus many other
properties.)  Perhaps stream_state or ios_state would be better.
- 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 
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 
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 ---

Boost list run by bdawes at, gregod at, cpdaniel at, john at