Re: [Boost-users] Format Library - Asterisk Support

From: Samuel Krempp (krempp_at_[hidden])
Date: 2004-12-01 13:30:48

On Sun, 2004-11-07 at 10:06, Samuel Krempp wrote:
> but adding the asterisk feature to boost::format neither, I just need to
> take some time and do it.. I'll try to do that this week.

It turns out there is a fundamental issue lying there, in case of
asterisk with a specified numbered position (by the "n$" syntax).
Given format's design (not storing copies or references of the given
arguments but instead formatting them one by one as they are being fed),
we need to know the width at the very time an argument is formatted.

So it is indeed very easy to support format strings such as 

format("%2$*1$d") % width % x; // order 1
or (abosutely equivalent) :
format("%*d") % width % x;

but the order between argument and and width parameter makes a big
difference, and :

format("%1$*2$d") % x % width; // order 2
(which is just equivalent to the previous one with posix printf)

is far more troublesome.

So I see 3 possible choices :
1/ add the asterisk feature but resticting it to "width before argument"
order (ie order 1 and not order 2)
parsing can be made compatible with order 2, and just use width 0 in
case with is passed after the actual argument.

2/ add the feature with any order, and work around the issue by some
hacking. 
basically, format the argument when it is given, and once the width
parameter is known : do the padding "by hand" - this implies *guessing*
where the padding should go within the formatted string, and is alread a
necessary hack for supporting some other exotic printf formatting
options. 
This hack comes at the cost of formatting twice the given argument, and
only works as long as the padding goes to one place only (always the
case with basic types, but user-defined types might split padding
between several places, and this obviously can not be "guessed" in
general)

3/ change format's core design, and have the format object store
references to each argument, doing the actual formatting only at the
end.
This would require more template complexity (the type of the format
object would evolve each time you call operator% on it), and would
introduce object-lifetime  issues, which were until now completely
avoided. 
Or we could store copies of arguments, which introduces copyability
issues..

Naturally, I'd choose 1, as it's simple to implement, and rather clean.

Does supporting the other order has any importance to you ? or anyone ?
in this case, additional patches could support order 2 via the
mentionned hack, but I'd rather not do that unless it's actually useful.

If order1 is all you need, I'd finalize my patch, run tests and commit
in the following days.

Regards,
-- 
Samuel