Re: [boost] Thoughts on Format

From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-01-24 00:15:10

> This is for the format library currently under review.
> 
> I haven't actually run the code due to my own compiler limitations, but I've
> taken a look at the code and read the comments on the list.  I agree with
> Robert Stewart that an approach like:
> 
> > Try deviating from the printf-like notation in the format string since this
> > isn't allowing for any printf-like functionality:
> > 
> > format("[3], [1] [2]-th try")[40.23](hex)[50]["toto"];

This format statement is rediculously overblown.  I have enough problems
with overloading the modulus operator to something non-directional.
making [] take non-integer arguments seems totally out of place.  

Can we stick to just the format with operator <<, format with operator
%, and format with variable arguments for the discussion?

I still think that it is not unrealistic to simply write

  format(cout,"%3$s, %1$s %2$s-th try") << 40.23 << hex << 50 << "toto" ;

It looks like a stream and it is compact. 

> > The [] pairs match in the format string as well as in the "parameters list,
> "
> > you always have delimiters on either side of the positional parameter, so
> > you don't need %n versus %{n}, and you get the syntactical difference
> > between values and manipulators.
> > 
> > This format offers a couple of valuable things. First, as someone pointed
> > out in another post, putting parentheses around manipulators allows the eye
> > to downgrade their importance in reading the expression. Second, we are
> > accustomed to subscripting operations being chained like this, whereas we
> > aren't accustomed to seeing chains of modulus operations. (I don't think of
> > this as subscripting any more than I think of << and >> as bit shifting
> > operations when working with streams. I just see the concatenation of
> > multiple subscripts as ordinary, and thus more comfortable.)
> 
> The current approach seems confusing, both in us trying to understand it and
> you trying to implement it.  The printf syntax explicitly mentions the type
> and formatting options for each parameter.  C++'s better type checking
> eliminates the need for the explicit typing, and the ability to add
> manipulator objects eliminates the need for explicit formatting.  You
> shouldn't have two radically different ways to do the same thing, so the
> printf interface should be dropped.  With just positional parameters, the
> library is easier to understand and create.

That would not well serve the purpose of allowing internationalization.
String translation services use printf.  It is a large standard which
we really should obey.  This point has been discussed multiple
times on the list.  Positional simply does not serve the needs of
a formating tool.

> By the way, Robert's approach doesn't mention about how to write brackets.
> Maybe we can have "%[" be a literal open square bracket, "%]" be a literal
> close square bracket, and "%%" be a literal percent.

Why must we confuse the user with dozens of new concepts like the above?
Printf format is well defined and widely used.  Besides in an mixed
code you would not want to send format strings with mixed formats.
This point has been discussed many times over.  If we are going to 
have a "formatted printing" it should be "formatted".  If you
want to resubmit a "reorder" manipulator for C++ streams it 
may be appropraite, but it does not negate the need for a 
formatted printing operator.

--Karl