From: Roland Richter (roland_at_[hidden])
Date: 2004-09-27 04:23:38
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