Re: [boost] Review : format2, yet another 'printf class'

From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-06-30 07:30:06

> > The second is "short-positional-notation", in which we
> > can indicate the number of the argument, nothing more.
> >
> > %2%  for second argument..
> > etc..
>
> This was the one I wanted most in my challenge. I don't like the idea that
> such a simple usage gets cluttered with extra % signs. Could we move the
> extra % to the printf syntax somehow?

Obviously no.. if we want to support printf-like syntaxe, we'd rather stick
to its precise specification.
And then, "%10" can either be followed by some text, say
"%10, "
or chars from printf specs; like "%10s" or "%10$2d", or "%10d", ...
So a short-positional notation can not be just "%N".

Still it's clearly practical to be able to designate arguments with just 2
letters.

One solution is to use another special char for this, say "$", like shell
syntax..
format(" $1s : $2=$$ $3") %"Taxe" %"Total" %"1500"
=>   " Taxes : Total=$ 1500"
The inconvenient is that another char ($ here) has to be escaped for
litteral usage.
And that the syntax of format becomes a bit bicephal..
But I think it is a good solution. providing both short and complex
notations satisfy both common but opposed needs
(quick printing of a few vars,  VS  basic formatted printing with alignment,
and all printf features like hexa printing etc..)

Would everybody be happy with these 2 forms coexisting ?
(in fact it makes 3, considering printf-like items can be positional :
"%1$s", or not : "%s" ..  )

If yes, I'll do that, the parsing should not be hard to adapt at all.

I think using both $1  and %2$5d  in the same format-string will even be
easy to implement.
(for cases when we just want a formatting stuff on 1 or 2 items, and want to
simply print the others..)
Within  a loop of long computations, say changing x, and y, it's often
practical to keep the values aligned :
format("$1, with ratio=$2.   found point [%3$4d, %4$4d]. \n") %fileName
%ratio %x %y;
->
toto.bmp, with ratio=0.83.   found point [   0,     0].
toto.bmp, with ratio=0.83.   found point [   5,    17].
toto.bmp, with ratio=0.83.   found point [  28,  176].
...
you get the point.
(even if I was too lazy to aligned by hand the numbers, with this stupid
Outlook using non-fixed font ..)

> > then, could the "format-as-a-function" previous implementation be
accepted
> > into boost ?
>
> I guess so. Maybe somebody else will have a counterargument. I like the
lack
> of arg limitations in your implementation.

well, the only concrete thing I see against the function approach, is the
few restrictions it imposes (const operators<< only, and 9 arguments max),
that feels a bit unfounded.

Also, lots of different function signatures get instantiated by the compiler
If we use format on 20 different types, with varying ordering of types in
5-arguments calls, we can get up to
20^5=3.200.000 different signatures. (ahh, I like the spectacular grandeur
of exponential growth..)
So basically,even if we rarely use more than 4 or 5 arguments, each call
will use a new signature, and there will be as many signatures as calls.
And this can maybe have some bad impact. In case not everything is fully
inlined, it would be catastrophic, wouldn't it ?

With the operator approach, only 5 different signatures of the operator% are
needed in this case.

I dont know enough of the internal structure of the compiled objects to know
if this can really lead to an undiscutable argument against the function..

Those points aside, the choice between operator and function approach is
merely up to tastes, and in this matter we're at least 2 to like the
operator..

Is there anybody willing to fight for the function-approach ?

--
Sam