Boost logo

Boost :

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. +49(0)179 2607481

Boost list run by bdawes at, gregod at, cpdaniel at, john at