Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-09-12 07:46:02


Hi Reece,

Here are some general comments:
----------------------------------

0. I think the library should be put in the directory
"boost/output_format"
I hate cryptic names.

1. In this example

   std::cout << boost::io::formatob( vec );
   // output: [ 1, 2, 3 ]
   std::cout << boost::io::formatob( vec ).format( "{ ", " }" );
   // output: { 1 : 2 : 3 }

why does the change of braces change "," to ":" ?

2. In this example

      int a[] = { 5, 4, 3, 2, 1 };
      std::cout << boost::io::formatob( boost::io::range( a, a + 5 ));
      std::cin >> boost::io::formatob( boost::io::range( a, a + 5 ));
      // output: [ 5, 4, 3, 2, 1 ]

it might be good to support a range version with the posibility to

1. throw if there is too few elements
2. default initialize if there is too few elements

3. cryptic name: formatob.hpp && formatobex; should be format_object and
whatever the latter really means

4. given std::cout << boost::io::formatobex< std::string >( v );

   maybe std::string should be a default argument?

5. A lot of boost::io::range() can be replaced with one Taking a Single Pass
Range

6. STL IO: It is not obvious how insertion is done? With push_back or by
overwriting elements?

7. why is it necessary with
           boost::io::formatob( boost::io::range( a, a + 5 ));
   could we not just say
           boost::io::range( a, a + 5 );

8. It should be possible to say

    vector<int> v = ...;
    cout << v;

without the format_ob() if I include stl.hpp, ie, overloads for all standard
types.

9. I would prefer basicfmt_t to be basic_format_type or perhaps basic_fmt_type
if the "fmt" shorthand is used consistently etc. That is, all the cryptic
    concatenation should be removed.

And now my review comments.

| When doing the formal review, please answer the following questions:
|
| 1. What is your evaluation of the design?

seems ok. I'm a little irritated about too cryptic names, concatenation and _t
types.

| 2. What is your evaluation of the implementation?

haven't looked.

| 3. What is your evaluation of the documentation?

good, although I miss return-types and template paramaters and some synopsises
with better overview.
For example, what does boost::io::formatobex< DelimeterType >( const T & ob );
return? Maybe it doesn't matter, but
then it should say <i>Implementation-defined</i>boost::io::formatobex<
DelimeterType >( const T & ob ); etc.

| 4. What is your evaluation of the potential usefulness of the library?

quite useful.

| 5. Did you try to use the library?
| With what compiler? Did you have any problems?

no.

| 6. How much effort did you put into your evaluation?
| A glance? A quick reading? In-depth study?

a quick glance.

| 7. Are you knowledgeable about the problem domain?

no.

| And most important,
| 8. Do you think the library should be accepted as a Boost library?
| Be sure to say this explicitly so that your other comments don't obscure
| your overall opinion.

yes. I think all issues can be dealt with quite easy for a post-review.

br

Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk