From: John Torjo (john.lists_at_[hidden])
Date: 2004-10-25 05:14:05
>>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.
> 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
> 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.
> - Should the library use locales and/or iword/qword?
^ pword, that is
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 possible
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
> 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.
Otherwise, I think something very trivial could be:
- provide support to write an array, with delimeters (open, in-between,
- provide support for writing a collection, with delimeters (open,
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:
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 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 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,
and once it's accepted, add more to it.
And if 3 months is unrealistic, we'll postpone.
-- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk