Re: [boost] Review request : format

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-12-20 16:51:48

> > Now, you can make
> > 
> > cout << format("%2 %1") << x << y;
> 
> Okay, then lets approach it a different way then.  
> 
>   format(cout, "%1$s %2$s" ) << x << y;
> 
> (which is the only other way I can get cout.format( "%1$s %2$s") << x << y; )
> 
> Now there is no question of what it is.  It is a function which returns
> a stream with reordering.  It can throw exceptions for under or
> overflow.  It obeys stream syntax and rules.  No endf is needed.

This is not so different really from cout << format << args 
operationally, though I agree it is clearer syntactically. In either 
case you have a new stream-like object.

There are two things I would worry about:

1) The conceptual binding of the format and the stream. The format 
really should be a distinct object, IMHO, since you should be able to 
apply the same format to several different output streams. But that's 
not so hard to deal with by using instead two constructors:

formatter::formatter(ostream &, format const &)
format::format(char const *); // Note not explicit...
format::format(string const &); // Completeness...

So I think this is not really an issue, just a nit with the way you 
wrote it originally.

2) The returned value may be a stream, but it is *not* a basic_ostream 
(obviously enough once you think about it). So it cannot be passed to 
functions which expect an ostream as an argument.

I don't think this is really a problem either, though it needs to be 
clearly documented. The only cases I could think of where ostream is 
passed as an argument are either handled correctly (eg, polymorphic 
printing through a single operator<<(Base &) and virtual member), or 
aren't something that could work anyway and will die with compile 
errors (passing the stream to a function doing output, expecting the 
output to be formatted per the format).

But, I thought I would mention it in case someone else could think of a 
case where it's a problem.

So I think this is a valid approach. I think it is cleaner syntax-wise than either of the other options, avoids the template expression machinery, allows some optimizations without too much of a headache... In general, I think I like it.

Can this be made to work to replicate scanf (with constant strings inside it) as well? I think it can, though I think there's less call for scanf...

George Heintzelman
georgeh_at_[hidden]