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

From: Dan Nuffer (dnuffer_at_[hidden])
Date: 2001-06-30 09:51:32

----- Original Message -----
From: "Samuel Krempp" <krempp_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, June 30, 2001 6:30 AM
Subject: Re: [boost] Review : format2, yet another 'printf class'

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

I wouldn't mind $, but I've done a bit of shell programming, so it's not
foreign to me.

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

I like the function approach, mostly because that's what I've been using for
the last 6 months :-)  I think that the code just looks more obvious with
what it's doing.  It's also easy to learn and understand.  I also see the
advantages of the non-function approach.  format could support both.
format could be a generator function (like std::back_inserter).  If it's
called with one char * argument it generates the format class that will
apply the % arguments, and if it's called with more than one argument, it
will generate the function type format class that wouldn't work with the %
operator.

--Dan Nuffer