In article <989aceac04102110261565afaf@mail.gmail.com>, Caleb Epstein wrote:

On Thu, 21 Oct 2004 04:47:01 -0400, Miro Jurisic wrote:

...

A typesafe solution is to use "format ("%1%") % string(buf, len)" if I understand the question correctly.

That would only work for string types. The * width specifier can be used with ANY type, e.g.:

printf ("|%*d|", 6, 42);

Yields "| 42|".

You know, I am sure I knew that in the back of my head, but I only ever used it for strings. Thanks. meeroh

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