|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk