Re: [boost] Thoughts on Format

From: James Kanze (kanze_at_[hidden])
Date: 2002-01-27 12:21:46

"Stewart, Robert" <stewart_at_[hidden]> writes:

|>  From:	Karl Nelson [SMTP:kenelson_at_[hidden]]

|>  > > > 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.

|>  Are you familiar with std::map?  It offers the subscript operator as
|>  a way of accessing elements, and the keys need not be integers.
|>  Consequently, there is precedence for non-integer arguments between
|>  "[" and "]".

Certainly.  On the other hand, when I see [][], I expect that the second
[] applies to the results of the first.  I also expect that the operator
implements something at least vaguely resembling a projection.  Anything
else is blatant misuse of operator overloading, and tends to justify
Java's omitting it.

While I"m at it, I might add that when the original iostream were
developped, a lot of thought went into the choice of the operator.
(Without member templates, the option of not using an operator at all
wasn't available.)  The choice of << wasn't just random.  The operator
had a number of things going for it; high on the list were an acceptable
precedence (which isn't the case for %), the visual aspect, and the fact
that most programmers probably weren't really using it for anything, so
associating the meaning output to it didn't create confusion.

As it is, % simply doesn't work because of the precedence, and [] leads
to confusion, as the operator is widely used, in just about every
program, for other things.

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

|>  No, but we can discuss that, too.

|>  > 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. 

|>  I'm not the least bit familiar with Unix98 printf() format
|>  specifiers, so I don't know what that format means.  (I purposely
|>  skipped that part of the documentation, because printf()
|>  compatibility is not important to me.)  I'm going to guess that the
|>  printf() % specifiers can have an embedded positional indicator
|>  which is a number followed by $.  Given that, and assuming that
|>  format complains at compile time when %s isn't given a string as
|>  shown in your example, 

It shouldn't complain, but rather format whatever it is given as a
string.  What that means needs some specifying, of course, but I don't
think it acceptable to refuse 0 for a "%1$f" specifier.  (As for compile
time checking, of course, that simply isn't possible, because in real
code, the compiler doesn't see the format string.)

|>  I still have one problem: I can't tell whether "hex" is a variable
|>  in scope at this point, or whether it std::hex brought into scope
|>  via some IOStreams header.  That may not be a likely point of
|>  confusion for "hex," but my point is that you can't tell that 50 is
|>  argument 2, not 3.

Which is yet another good argument to not use manipulators.

-- 
James Kanze                                mailto:kanze_at_[hidden]
Conseils en informatique orientée objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. [phone]