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]