Boost logo

Boost :

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
> > 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
> 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
> 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
> 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
> 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%
> needed in this case.
> I dont know enough of the internal structure of the compiled objects to
> 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 %

--Dan Nuffer

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