"John Torjo" <john.lists@torjo.com> wrote in message news:417CD1ED.604@torjo.com...
Reece will redesign it, given the feedback and a new formal review will take place in about 3 months.
Are you also taking back your suggestion that the 2nd review be abbreviated? It seems to me that the only reason to have a short 2nd review would be if some preliminary conclusions had been reached in the first review. If I recall
I will prefer an abbreviated review. Depending on how much feedback is received, I might choose to extend it.
Okay.
correctly, there were at least 4 distinct ideas about how the library should be redsigned, with no clear preference for one alternative among participants in the review. If, as review manager, you believe there was enough consensus on certain issues or you decide independently that certain solutions are technically best, you should state this in the review result.
Here are some of the open issues: - Since renaming is required, what should the new names be?
Renaming can happen at a later time (not now, that is). It can also happen during the review. It's happened before. Also, this is relevant if the library is accepted.
I agree. I'm just pointing out that this issue was not resolved and therefore might be expected to take up some time during the second review.
- Should the library use locales and/or iword/qword? ^ pword, that is
Yes, pword ;-)
This is an implementation detail.
- Should the library be a lightweight facility for debugging or a full-flegded formatting facility which allows an object to be output in almost any
Agreed. But implementation details are an important subject for review discussions. possible
way?
It should be an in-between.
I would like it on record that I disagree with this decision.<snip> I still not sure that problem domain doesn't warrant library at all.
At the just completed Redmond meeting, the library working group voted to remove tuple i/o from TR1, partly because of some difficulties with the specification. But there was unanimous agreement that some standard i/o facility is needed for all STL containers, and substantial support for a certain degree of customizability.
Therefore, I think the best way to procede would be to develop two proposals, which might be combined into one library:
1. An ultra-lightweight version which could be a candidate for standardization, providing both input and output and minimal support for user customization. This version should work by overloading operator<< in namespace std, and be implementable with very little metaprogramming.
For starters, I thinkg you should be able to use boost.serialize.
As I stated in my review, I conceive of the output formatters library as an inverse to Spirit. I'n many cases loss of information is desirable, so there is no natural way to support input. However, I'm now proposing *in addition* a lightweight facility that could become part of the standard library. My impression from sitting in with the library working group is that both input and output would be desired for such a facility. While I admire Boost.Serialize very much, and might like to see it standardized, it's obviously not what is needed to fix the embarrassing lack of stream inserters and extractors for standard containers.
Otherwise, I think something very trivial could be: - provide support to write an array, with delimeters (open, in-between, close). - provide support for writing a collection, with delimeters (open, in-between, close).
This is very lightweight, and a constraint is that open != in-between and close != in-between (so that you can read back an array).
You'll write things like:
std::vector<int> v; v.push_back(1); v.push_back(3); v.push_back(4);
std::cout << write(v, "[ %, % ]"); // [ 1, 3, 4 ] std::cin >> read(v, "[ %, % ]"); // read back std::cout << write(v, "[ %\n% ]"); // [ 1\n3\n4 ]
A facility for escaping strings will also be needed.
I will make some time later this week, and come up with a very lightweight version of this. (in the meanwhile, I'll also look at Rozental's implementation - maybe that's all we need)
And just to make it clear once again: The "Output Formatters" library *should not* provide Input facilities (Reece, please take note!)
2. A highly-customizable framework for formatting more-or-less arbitrary types. This proposal might be seen as an inverse to Spirit. IMO, it's worth
I've written a sample implementation over the weekend which I'll post as soon as I have time to document it. Sample use: // pseudo code initialization: vector< list< pair<string, string> > > v = { { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") }, { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") } }; int flags = punc::indent_after_open | punc::break_after_sep; cout << punctuate< vector<_> >("[", ",", "]", flags) << punctuate< list<_> >("{", ",", "}", flags) << punctuate< pair<_, _> >("(", ":", ")") << v << "\n"; Output: [ { (hello:goodbye), (morning:evening), (cold:hot) }, { (hello:goodbye), (morning:evening), (cold:hot) } ] It provides input and output, but no string-escaping (yet). Right now, a string is regarded to be complete as soon as an appropriate punctuaion sequence is encountered. pursuing
several of the ideas brought up during the review, to see how they compare. As much as I'd like to see this happen soon, I think three months is unrealistic.
It's so funny, during reviews, everyone comes up with his own better version of the reviewed library.
Reece's lib has been in the sand-box for so long, and nobody said anything.
I hope you're not directing this remark at me. I've worked with Reece on his library since before it was in the sandbox. Early on I sent him some sketches of my ideas for his library, and was hoping to produce a sample implementation. Unfortunately, I got too busy.
Best, John
Jonathan