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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
