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@hotmail.com> wrote in message
| [2] The direct result of not supporting [1] 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 and again. - Roland