FORMAL review of "Output Formatters" - votes needed
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. My personal vote is "No". Please share your own. Best, John Review Manager -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
"John Torjo" <john.lists@torjo.com> wrote in message news:41544F74.7010501@torjo.com...
Dear boosters,
To conclude, I would like to ask you to vote: - "Yes" - in favor of Input facilities - "No" - don't want Input facilities.
I think I was clear about this in my review, but to avoid any confusion, let me repeat that my vote is No. Jonathan
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.
My personal vote is "No". Please share your own.
Best, John
Review Manager
My vote is NO. Would I want library like this, it should be output only. To parse complex input I could use Spirit. To parse any input format that should coincide with output format I would use serialization lib. Gennadiy.
"John Torjo" <john.lists@torjo.com> wrote in message news:41544F74.7010501@torjo.com...
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.
My vote is NO input facilities. Input can best be accommodated via Spirit, regex and/or tokenizer. Furthermore, the discussions on changes to the output facilities are such that I would vote that the library should be shelved, the documentation and design reworked, and the library re-submitted. Jeff Flinn
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.
My personal vote is "No". Please share your own.
I don't know if I am allowed to vote here, but I would like to point out a few things: [1] The library provides operator << (output) for STL containers. Thus, you can do: ss << vec; If input facilities were not provided, you couldn't do: ss >> vec; // oops! operator >> not defined for std::vector<...> NOTE: You would then need to implement these facilities using Boost.Spirit which will add a dependency on that library. [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 ]" ); [3] Input and output operations are symmetric operations. Why provide output for std::complex if you don't provide input? Boost.Spirit does not provide output functionality because it is designed as a lexer/parser implementation tool that are focused on input processing only. Regards, Reece
"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:41549378.5060205@hotmail.com... | [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'); br Thorsten
Reece Dunn wrote:
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.
My personal vote is "No". Please share your own.
I don't know if I am allowed to vote here, but I would like to point out a few things:
[1] The library provides operator << (output) for STL containers. Thus, you can do:
ss << vec;
If input facilities were not provided, you couldn't do:
ss >> vec; // oops! operator >> not defined for std::vector<...>
NOTE: You would then need to implement these facilities using Boost.Spirit which will add a dependency on that library.
[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 ]" );
[3] Input and output operations are symmetric operations. Why provide output for std::complex if you don't provide input?
When they're symmetric, I can use [serialize]. The thing is that when I want pretty output, I want your library. When I do pretty output, I really don't expect to read it back. For a lot of cases when I do pretty output, there is no safe way to read it back. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
While it might seem nice to have symmetry here, I think the emphasis is on HUMAN-readable output. MACHINE-readable formats would be shorter and probably not human-friendly. So my vote is NO REQUIREMENT for input facilities. But if they have no 'cost' then I vote YES for including them. In other words, I am sitting on the fence ;-) Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of John Torjo | Sent: 24 September 2004 17:47 | To: Boost list | Subject: [boost] FORMAL review of "Output Formatters" - votes needed | | 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. | | | My personal vote is "No". | Please share your own. | | Best, | John | | Review Manager | | | | | | -- | John Torjo | -- john@torjo.com | | Contributing editor, C/C++ Users Journal | -- "Win32 GUI Generics" -- generics & GUI do mix, after all | -- http://www.torjo.com/win32gui/ | -- v1.4 - save_dlg - true binding of your data to UI controls! | + easily add validation rules (win32gui/examples/smart_dlg) | | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost | |
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
"Roland Richter" <roland@flll.jku.at> wrote in message news:4157DC09.4000405@flll.jku.at...
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.
Trying to vote three times? You should at least use aliases for the other two votes ;-) Jonathan
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
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
Roland Richter wrote:
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.
And why just support operator << for the STL containers and not >>? If I drop input facilities from my library, this is what will happen. Also, you'd need to implement operator >> somehow for the STL containers in order to be complete. The question then becomes: how? I have been working on improving my library based on the feedback from the review and one of the things that has been revised is the input facilities, making them sit more naturally with the input streams framework, removing the need to provide a special wrapper around an input stream.
Then, again, the name "Output formatters" is already misleading.
Which will most likely become the Collection I/O Framework (io::collection).
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.
I have thought about this: in the operator>> body, save the old skipws flag state and enable whitespace skipping; proceed to input the collection; restore the state of the skip flag. Regards, Reece
participants (8)
-
Gennadiy Rozental -
Jeff Flinn -
John Torjo -
Jonathan Turkanis -
Paul A Bristow -
Reece Dunn -
Roland Richter -
Thorsten Ottosen