John Torjo wrote:
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.
- Should the library use locales and/or iword/qword? ^ pword, that is This is an implementation detail.
How? The difference between: locale::global(locale(), new vector_io_facet(.......)) and cout << vector_io_format(......) is in interface, not implementation.
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.
It's too large, for starters.
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)
Hmm... are you about to write some code? Isn't this a bit contrary to review manager role -- he's supposed to be non involved in the development of the library that's being reviewed.
And just to make it clear once again: The "Output Formatters" library *should not* provide Input facilities (Reece, please take note!)
Now, I don't want to start a revolution, and I don't have anything against you in personal, but there are some points: 1. The library is rejected. Only another review can make it enter Boost. 2. We don't have a rule that re-review must be managed by the same person who managed the first review. We don't have any "library won't be re-reviewed unless do change this and that" resolution. So I don't think it's OK to require Reece to remove input facilities. I don't think input facilities caused any big problems, and we can't be sure they cause problems in a redesigned library. 3. It's a bit problematic that you start to take part in design discussion/development. And just for a record: I count 4 "no" votes for input (including yours) and 2 "yes", which means that 1/3 of all the users want this.
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 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 was using an alternative library from the same sandbox, for example. I'm not sure if Reece used to post a periodic preliminary versions.
I will talk to Reece, so that he'll update the docs showing how he wants to redesign his lib. If there's (negative) feedback, he'll update.
If I were Reece, I'd go with a semi-highly-customizable lib at first,
Ohh... what's "semi-highly-customizable"? The "highly-customizable" is vague itself, not to mention "semi" ;-) - Volodya