RE: [boost] OutFrmt lib design questions

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2004-09-21 11:45:01

> >Here some question I've got while reading submitted library.
> >
> >1. What is an advantage if using this library for scalar types (vs.
> >defining
> >operator<<)
> 
> Do you mean for things like int, Person, etc. If that is the 
> case, the 
> default behaviour of the library is to delegate output of 
> these types to 
> operator<<, so it doesn't do much. However, with support for a 
> fmt::serialize formatter that calls 'serialize' instead of 
> <<, you can 
> register a particular class as being serializable so my type 
> deduction 
> system knows to associate instances of that type with 
> fmt::serialize, so you 
> can then do:
> 
>    // new design
>    std::cout << io::object( my_serializable_object ) << '\n';
>    std::cout << io::object( vec_of_serializable_objects ) << 
> '\n'; // [ ..., 
> ..., ... ]

I don't really interested in another serialization library. We already have
one.
 
> The advantage of using this for things like std::complex or 
> boost::math::quaternion that already supply << and >> 
> operators is if you 
> want to have control over how a type is rendered, e.g.:
> 
>    // new design
>    std::cout << io::object( complex_val ).decorate( "", "", " + i" )
>       << " = " << io::object( complex_val ).decorate( "( ", " 
> )" ) << '\n';

And you believe that I will keep repeating this code every time I need to
print my complex value?

 
> >2. If primary target is collection formatting wouldn't it be 
> better to 
> >name library "collection formats something"?
> 
> This is a good idea. The name is from when the library just 
> had output 
> support, thus the "outfmt" directory in the sandbox. I am 
> thinking about 
> moving to a "formatter" directory. What do other people think?
> 
> >3. If there is a way to assign format to collection/type combination 
> >permanently (through global operator <<), why would I want 
> to do it in 
> >every instance of output operation?
> 
> Do you mean:
>    std::vector< int > vec;
>    std::cout << "vector = " << vec << '\n'; // [1]
>    std::cout << "vector = " << io::formatob( vec ) << '\n'; // [2]
> 
> using [1] vs using [2]? If so, these are the same, but the 
> second allows you 
> to customize the decoration around the sequence, for example:
>    std::cout << io::formatob( vec ).format( " : " ); // [ 1 : 
> 2 : 3 : 4 ]

No my question was Is there a way to assign custom (meaning different from
one you selected) decoration permanently. 
 
> >4. What is an advantage of using this library to assign format to 
> >collection/type combination permanently vs. explicit implementation 
> >(using FOREACH construct for example)
> 
> Using a foreach construct you would need to hand-code the surrounding 
> decoration, e.g.:
> 
>    // output: { a + b + c }
>    std::cout << "{ ";
>    foreach( char ch : vec )
>    {
>       std::cout << ch;
>       if( !atend ) std::cout << " + ";
>    }
>    std::cout << " }";
> 
> vs:
> 
>    std::cout << io::formatob( vec ).format( "{ ", " }", " + " 
); // output: 
> { a + b + c }
> 
> If you have a nested construct, such as int tictactoe[ 3 ][ 3 
> ], std::list< 
> std::list< float > > or math::matrix4x4< float > then 
> outputting/inputting 
> it manually would be more complex, whereas my library has all 
> the machinery 
> to handle this simply.

Yeah. But I do it only once. And using foreach is way more flexible. I don't
believe your library bring any advantage in this scenario.
 
> >5. Why do we need boost::io::range? Couldn't we use boost::range 
> >instead?
> 
> I suppose it would be possible to use 
> boost::range::make_iterator_range 
> instead. The only thing I have against this is its length. Consider:
> 
>    // new design
>    using boost::range::make_iterator_range;
>    namespace range = boost::range;
>    namespace io = boost::io;
> 
>    std::cout << io::object( range::make_iterator_range( i, i 
> + 7 )); // [1]
>    std::cout << io::object( make_iterator_range( i, i + 7 )); // [2]
>    std::cout << io::object( io::range( i, i + 7 )); // [3]
> 
> If only you could alias functions, e.g.:
>    namespace io{ alias range = boost::range::make_iterator_range; }

IMO you shouldn't introduce yet another range notion.

 > >6. In a formatter usage how would I guess what is what?
> >    boost::io::formatter< char * > fmt( "\ ", " /", " | " );
> >    boost::io::formatob( vec, 
> boost::io::containerfmt()).format( fmt );
> 
> I have revised the names, so that is now:
>    namespace fmt = boost::io::format;
> 
>    io::sequence_decorators< char > seq( "\\ ", " /", " | " );
>    io::object( vec, fmt::container()).decorate( seq );

IMO it's really bad idea to introduce interfaces that change meaning depend
on number of arguments of the same type. Moreover it easy to confuse one
with another.

Your interface: 
( str1, str2, str3 ) - open, close, separator
( str1, str2 )         - open, close
( str1 )                 - separator

Now If I do not use your library on everyday basis, And look on invocation
of first function - how would I now what is what.

There should be something that tell explicitly - here is open/close
brackets, here is separator.
 
> >7. Who come format calls order dependent?
> >  boost::io::formatob( vec, boost::io::containerfmt()).format( fmt
> >).format(
> >" : " );
> 
> format( fmt ) is called first, then format( " : " ). Thus, 
> you will have "\ 
> a : b : c /" as the formatting.

You did not answer the question. I believe that interface is incorrect if it
order dependent
 
> >9. Let say I print vector<char>. Is there way to print it 
> like this: { 
> >'a', 'b', 0x01, ' ' }

Actually I did not want '' around hex value - intent was to print array in
c++ format.
 
> Yes. You need to provide a wrappedfmt() format object. For example:
> 
>    formatob( vec, containerfmt( wrappedfmt().format( "'", "'" 
> ))).format( "{ 
> ", " }" );
>    // output: { 'a', 'b', 'c' }

So this wouldn't wark for me since I do not want '' around some of the
values.
 
> With the 0x01 character, special treatment needs to be 
> applied. You will 
> need to supply a custom format object to see if the character 
> is printable, 
> e.g.:
> 
[your 20 lines solution skipped]

IMO In this scenario your library doesn't stand  a comparison with
handcrafted solution.

> 
> Regards,
> Reece

Gennadiy.