Re: [boost] IO Formatting Manipulators

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2003-05-08 11:56:00

John Torjo wrote:

>Sorry for the late reply...

Don't worry about it - I've been kinda busy lately

>The library is in great shape!!!

Thanks :-)

>I love the idea behind format_traits! formatob as well!

>Why did you opt for the .space() function? I think it could have been
>included in the .format function? I don't think it was for efficiency...

The .space() function was a legacy of when I only had support for char
types and there was no string support. It is essentially redundant now
that I have character strings support, but I have kept it for compatibility.
I did not put it in the .format() function because that would get confusing.

Question: Should I drop the space options in the formatter?

>Wouldn't it be easier if (I think) in formatlist_t, when deriving from:
>class formatlist_t: public detail::list_output< FormatType, formatlist_t<
>  ForwardIterator,
>  FormatType,
>  Outputter >, Outputter >

>you could derive from something like:
>class formatlist_t: public detail::list_output< FormatType, formatlist_t<
>  ForwardIterator,
>  some_traits_whatever< FormatType>,
>  Outputter >, Outputter >

In order to move away from specifically using format_traits? I'll look into
this (another thing on my todo list)! But this is essentially the same as
creating a formatter and supplying that to the manipulator generator.

   boost::io::formatter< char > fmt;
   fmt.format( '{', '}' );

>So, instead of keeping chars, in formatlist_t<..., char> or whatever, you
>would ALWAYS keep strings.

I'd like the option -- std::string would perform slower than a string 
constant.
I'm looking at supporting std::basic_string types in format_traits (again, 
this
is on my todo list).

>This way, there would be no need for chars. How 'bout it?

Again with the performance.

>---------------

>The formatter generators (formatob) concept is very powerful. Maybe you
>could insist more on it on the documentation.

I have been busy lately, so I have not had much time to work on the
documentation. Thanks for the input though.

>I am kind of puzzled why you need both formatlistfn and formatob. Could you
>enlighten me?

formatlist - list output including containers, sub-lists and arrays
formatob - any basic type (i.e. non-list)

formatlist has several variants:
formatlist - standard list formatting
formatlistex - specify the format type
formatlistfn - list formatting with a specialist outputter
formatlistfn2 - the formatter_t variants (not posted yet)
-- this is to stop compilers complaining about matching the template
arguments

>------------

>By the way, how about providing an operator << for the STL containers
>(vector, list, deque, map, multimap, set) that just does a
>'boost::io::formatlist( v )'???
>(eventually with a posibility to turn off)
>I think it would be helpful, and writing could be straightforward. In case
>the user wants more, just use boost::io::formatlist.

Possibly -- wrap it in a preprocessor if statement. Or have it as a seperate
file:
   #include <boost/io/stl_io.hpp>

>--------------

>I think it's possible to determine, in function boost::io::formatlist, if a
>container is associative or not. Therefore, it would simplify writing
>maps/multimaps/sets/etc. to streams.
>I could dig further to see if it's possible.

Interesting... and more things to do!!!!

>--------------

>P.S. What did you use to generate the docs? It's really COOL!!!

I used my own XSLT stylesheet; I could e-mail you the source if you want.
It is large, BTW - 236kb zipped!

Thanks for your feedback,

Reece.

_________________________________________________________________
Get Hotmail on your mobile phone http://www.msn.co.uk/mobile