[boost] Re: formatter

From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-12-15 12:50:01

On Thu, 2001-12-13 at 22:57, Karl Nelson wrote:
>   -  Why use %?  It isn't stream like and it has different presidence
>      rules.   There was a very long discussion of using << when I
>      submitted my original code.  The conclusion was stick to <<. 

the different precedence is precisely the reason for its use.
This makes it possible to do
cout << format(" n = %1 ") % n <<  ": bad value.\n";
, or any other mixing of format objects with stream operator <<, 
_cleanly_ .

Otherwise, cout << format(" stuff ")  is called first, and you have to
make it return a proxy, and then you cant guess when the user stops
feeding arguments into the object and whether he might want to continue
outputting to the stream.
it makes the code less clear, and causes trouble to recognize the end of
parameters..

So using an operator with a different precedence really makes life
easier.

On the other hand, the problem with '%' is only that we use yet another
operator. It seems a lot of people completely dislike this eventuality,
but I don't see why it would be such a problem. it's not ugly.
in fact it's even shorter. 
It can not be mistaken for the usual arithmetic meaning of '%'.
there is no technical issues..
It seems to me the only drawback of operator% is psychological.

(BTW, using %  to feed arguments to a formatter makes sense for python
programmers, so it is not completely unheard of as it may seem at first
;-)

I think it's better like this, except if we decide that we won't mix
format's operator<< with stream's, but instead do it as Vonosan does :
  fmt << "Hello" << "world";
  cout << fmt.str() << endl;
This way, there is obviously no need for another operator dedicated to
feeding arguments into the format object.

but I think loosing the ability to mix format objects and streams (eg
the code example in the beginning of this message) is a big price to
pay.
problems do arise when we mix them, as vonosan stated, but currently my
format object, by using operator%, managed to avoid them.

so  imho these are the 2 possibilities :
1) stick to '<<' but dont use format objects in the middle of
cout << ....
lines

2) allow whatever mix the user want with streams and format objects, but
using operator% to feed arguments into the format object.

(obviously I chose solution 2)
 

>   - Why place a "p" for the printf type.  Why not use %1& or some 
>      other code for  %1$s?   Since translators do not know where
>      the string is created in the program  (could be a printf or
>      a format) you should not alter the standard.   If you must
>      have a short cut for "%1$s", use the same format as printf
>      otherwise you get ambiguity.  Does this mean argument 10 or
>      argument 1?  "%100 -- %2 %3" 
> 
>      Why have the option of not specifying the type at all to save
>      2 charactors while breaking compilence with the existing
standard? 

because my guess is half the users wont care about printf compatibility,
but will want the most concise form possible.

for printf compatibility, my current fix is to provide an alternate
format class : pformat.
the html doc says :
Note : You might want to use printf directives directly. To this end,
format constructors take a parameter that can be used to set "printf
mode". We provide wrapper functions pformat (and wpformat for wchar_t)
that returns such a format object. With pformat, the format-string
accepts printf directives directly (eg %#x )

So, if you want to use a format-string intended for printf, you can
simply call pformat, it will act as intended.

btw, "%100 " means argument 100. (we stop reading the argument-number at
the first non-digit character)

if you want to output %1, immediately followed by "00", the
'short-style' is not possible. you can type : "%p1$s00"
Of course, this _is_ a limitation of this 'short-style' syntax.
But this syntax is just provided to write concise format strings for the
most common needs. It is not intended for all possible uses.

> This code is not suitable for my use in the GNOME standard where 
> I must have strict complience to other GNOME codes.  :-(

using pformat would make it possible to keep this strict compliance ?

-- 
Sam
PS : I'll send another email soon, to describe the current concern with
my format class : the impossibility to fully emulate printf directives
for some rare directives.
And I'll upload my local updated code to the vault, the one there is
much uglier. ( user calls to clear() is no longer necessary..)