From: Roland Richter (roland_at_[hidden])
Date: 2004-09-27 04:23:21
John Torjo wrote:
> Dear boosters,
> There's been quite a hot debate about "Output Formatters" library.
> Reece has provided some input facilies in this library as well.
> This has drawn people to either sides: some don't want these input
> facilities, while others do.
> To conclude, I would like to ask you to vote:
> - "Yes" - in favor of Input facilities
> - "No" - don't want Input facilities.
I vote "Yes", but I realize that I'm already outnumbered
and I'm too late.
The dilemma I see is that the outfmt library is somewhere
between serialization (boost::serialization) and pretty-printing
(boost::format). IMO, outfmt provides *both* at a basic level
in that it simply adds streaming operators << and >> to STL
containers, which, for some reason, are currently missing.
Then, again, the name "Output formatters" is already misleading.
> Thorsten Ottosen wrote:
>> "Reece Dunn" <msclrhd_at_[hidden]> wrote in message
>> |  The direct result of not supporting  is that you cannot utilize
>> | Roland Richter's usage:
>> | std::list<char> cl = lexical_cast< std::list<char> >( "[ a, b, c ]" );
>> just a remark: this can be done with boost.assign:
>> std::list<char> cl = list_of('a')('b')('c');
Not if the string "[ a, b, c ]" comes from a file or, as in my
case, from the Java side via a JNI interface.
This does not require much formatting; to be precise, it requires
formatting just because lexical_cast does not accept whitespace.
Then, again, as Vladimir Prus wrote:
> I've made a noise about this in the past. I strongly believe that current
> lexical_cast behaviour does not play nice with existing stream operators
> (which are commonly written to assume whitespace is skipped). There's no
> good reason for that, and lexical_cast should not use the "noskipws" flag.
and I already decided to incorporate a modified version of lexical_cast
into my project, because I'm sick to run into that kind of problem again
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk