From: Samuel Krempp (krempp_at_[hidden])
Date: 2002-01-28 07:09:54
On Sun, 2002-01-27 at 17:43, James Kanze wrote:
> First, of course, '%' is out of the question, since it has the wrong
And in another message :
> As it is, % simply doesn't work because of the precedence
I don't agree with you.. it works.
and it has worked for python too, for years.
You reject operator% because its precedence is higher than that of +/- ?
If a user makes a mistake, like
format(format_string) % 1+2 ;
it's catched at compile-time.
It's the same in python, and it never was that much of a problem for
Python 2.1.1+ (#1, Jan 8 2002, 00:37:12)
>>> print("%d") % 1+3
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: cannot add type "int" to string
I believe users are able to notice that with '%', + and - oeprations are
to be placed into parentheses.
If they don't notice it at first, the compiler tells them, and then
they'll know it.
Needing parentheses for + and - may be a small inconvenience,
but I don't see that as a decisive argument at all.
> If an operator is wanted, what's wrong with
> <<; it is currently the formatting operator, so why change it.
That's the real argument. You don't want '%' because you want '<<',
which precedence is a little bit different, and as a result you blame
'%' for not having the same precedence.
I preferred changing it, because passing arguments to a format object
is not exactly like passing them to a stream, I don't think we should
make it look the same.
this was already stated,
cout << format("%1$d %2$d") << x ;
cout << y;
This is the most obvious sign that the format object is not behaving
like a stream-modifier.
There are other, subtler possible traps for users who are fooled by the
similarity with stream's '<<'.
One thing I don't like at all, is what happens once you are done with
the arguments for format, but want to continue using the stream.
You wrote the following lines, in another message :
> |> It's a little easier to see the <<'s in the second statement than
> |> the %'s in the first. Unfortunately, using "<<" introduces
> |> interacting with streams,
> Is this from experience, or simply speculation? I was worried about
> same thing in my format class, and hesitated for a long time (using
> operator,()). In the end, I bit the bullet, and in practice, it has
> never caused any problem. The one thing I did have to do at a
> site was recognize ostream manipulators, and use them to terminate the
> format, and shift back to outputting to the ostream. The rule sounds
> horrible and unorthagonal, but works well in practice, where people
> write things like:
> logfile << GB_Format( "..." ) << x << y << std::endl ;
Okay, so you have some overloads that make this things work, the rules
are horrible, but as long as the user doesn't try incredible things, it
works as he thinks it does.
Personnally, I prefer using '%', accepting the different precedence, and
desinging my format to have the simplest of behaviours, independantly of
what the user will want to do with the stream, after using format.
In my opinion, the different precedence is nothing, compared to the
'horrible rules' it saves us from.
And if indeed the choice is mine, I am going to keep '%' when proposing
the final library.
I'll just have to hope it won't be causing too many vetoes..
(I know now that I need to write more arguments on that in the html)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk