Re: [boost] Review request : format

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-12-20 15:08:09

On Thu, 2001-12-20 at 02:52, Karl Nelson wrote:
> > It could, but then in those cases it would act like a string-maker, not
> > a manipulator.
> 
> I gave this a bit of thought and I think that format really shouldn't
> be a manipulator.  It should be a method of an ostream...
> 
>   cout.format("There are %d items\n") << i;
> 
> However, in the face of the fact that I can't get it into 
> standard in that form.  I think manipulator is best.

I would love it to be a manipulator. That is, as I said somewhere, the 
ideal. But I have been thinking about this problem a bit, and it's not 
easy (possible?) to make it a true manipulator. You can make it 
something that looks kind of like a manipulator, but isn't, at best.

Consider:
int x,y;
cout << format("%2 %1");
cout << x;
cout << y;

There's really no way to make this work without changing the way the 
underlying IOstreams work, because you can't avoid calling 
operator<<(ostream &,int), and the only hooks that function lets you 
used are the pretty rigidly constrained locale facets.

Now, you can make

cout << format("%2 %1") << x << y;

work by having operator<<(ostream &, format &) return some other object 
which defines a templatized operator<<. This is probably fine for most 
applications of this format object, but it is somewhat misleading to 
the user about what it is really doing, and I don't think it 
necessarily buys us anything in efficiency or principle over operator% 
(more below).

Having come to that conclusion, I think the formatter object shouldn't 
pretend to be manipulator, as pretending to be something you aren't 
just confuses people.

*However* I don't think that that frees us from wanting to avoid (or at 
least allow the avoidance of) string copies, and to allow const format 
objects. Contrary to my previous claim, I think this goal is still 
achievable with the operator% syntax, if one is willing to apply a 
little template magic (it is definitely bind-like, except that the 
function applied late is known to be operator<<). But to allow that 
kind of optimization for some later ambitious programmer, I think we 
should be careful not to overspecify the interface of the original 
format object. In particular, the result of operator% should not be 
specified to itself be a format object (though it would be allowable, 
if some implementation found it convenient), and operator%(format const 
&, T) should be allowable if there is any likelihood that format's 
constructor will use any significant resources. I think that 
pre-parsing the format string is a definite possibility for an 
implementation, so I will want that capability.

George Heintzelman
georgeh_at_[hidden]