From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-03-26 15:20:57


>From: "Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]>

> > #include <boost/io/format/std/vector.hpp>
> > #include <boost/io/format/std/map.hpp>
> > #include <boost/io/format/array.hpp>
>
> I am afraid boost/io/format will be confusing in a sight of presence of
> Boost.Format.

I understand. Well, it's in a different namespace.

> I would prefer (since it all about container output formatting)
>
> boost/io/container

Well, it actually may handle any composite type, such as std::complex,
std::pair, etc., as well. It also handles any sequence (using
io::sequence<Type>(begin,end) ), not just containers.

I used to call it "composite_format", but that was rather long... Using
"io::format<Type>(...)", I think is quite succinct.

> Also it could be stl instead of std, though it's the matter of taste.

The directories follow the namespaces, so it has "std" and "boost". STL is
only a subset of the standard library, so also for that reason, I think
"std" would be more appropriate.

> > std::cout << format<value_type>("[", "]\n", " => ")
> > << format<map>("","","")
> > << values;
>
> ...
>
> > Syntax
> > ----------
> > format<Type>(<start sequence>, <end sequence>, <delimiter>, [<start
> > element>, <end element>])[.set_default_format()]
> > format<Type>(<set/unset format>)
>
> I personally would really prefer verbose format specification. So I should
> not remember what each of the parameters means by it's position.
> Something along this lines:
>
> std::cout << start_elelment<value_type>( "[" ) // if you need value
> type_here. I am not sure

Yes, you do, or it won't know which type to set it for.

> << end_element<value_type>( "]\n" )
> << element_delimeter<value_type>( " => " )
> ...
> << values;
>
> Or
>
> std::cout << format<value_type>().start_elelment( "[" ).end_element( "]\n"
> ).delimeter( " => " )
> ...
> << values;
>
> Or mix of this styles. Or - the very best - all of them.

This should be quite easy to add. The latter style is also used in Reece
Dunn's list manipulator, which also deals with output for sequences.

I don't have that much practice with it, but I've found myself that I don't
have a problem remembering which parameter is what, in the 3+2 optional
parameter list. Lack of verbosity may be considered one of the advantages
over writing explicit output code.

Thanks for the feedback.

Regards,

Terje