Hi, I have noticed that the format library does not support at present the printf asterisk for providing dynamic width as an extra parameter. Unfortunately my users need to use this widely and I would really hate to revert back to a non-typesafe solution. a. Are there any plans to support it in near future? b. If not, is there an easy way to add that to parsing.hpp, parse_printf_directive method, parse_width & parse_precision sections? currently the asterisk is ignored, and the library throws an exception thinking it has an extra parameter. c. Is there any workaround I miss which may give me the same expected result of providing say "%*s, width, charPtr" ? (I have 'width' and a non-null-terminated char pointer and need to construct the correct string from them without doing unnecessary copying...) Many thanks, Barak ________________________ Barak Simon GED IT Core Platform Deutsche Bank 190 George St. Sydney, 2000 Phone +61 2 925 85070 Fax +61 2 925 95050 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
In article <OFED98622A.E7230120-ONCA256F34.002B3C63@db.com>, "Barak Simon" <barak.simon@db.com> wrote:
I have noticed that the format library does not support at present the printf asterisk for providing dynamic width as an extra parameter. Unfortunately my users need to use this widely and I would really hate to revert back to a non-typesafe solution.
A typesafe solution is to use format ("%1%") % string(buf, len) if I understand the question correctly. hth meeroh
On Thu, 21 Oct 2004 04:47:01 -0400, Miro Jurisic <macdev@meeroh.org> wrote:
In article <OFED98622A.E7230120-ONCA256F34.002B3C63@db.com>, "Barak Simon" <barak.simon@db.com> wrote:
I have noticed that the format library does not support at present the printf asterisk for providing dynamic width as an extra parameter. Unfortunately my users need to use this widely and I would really hate to revert back to a non-typesafe solution.
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|". -- Caleb Epstein caleb.epstein@gmail.com
In article <989aceac04102110261565afaf@mail.gmail.com>, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On Thu, 21 Oct 2004 04:47:01 -0400, Miro Jurisic <macdev@meeroh.org> 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 Thu, 2004-10-21 at 10:14, Barak Simon wrote:
Hi, I have noticed that the format library does not support at present the printf asterisk for providing dynamic width as an extra parameter. Unfortunately my users need to use this widely and I would really hate to revert back to a non-typesafe solution.
a. Are there any plans to support it in near future?
I was waiting to see if any people would need the feature before implementing it.
b. If not, is there an easy way to add that to parsing.hpp, parse_printf_directive method, parse_width & parse_precision sections? currently the asterisk is ignored, and the library throws an exception thinking it has an extra parameter.
hum, in the meantime ignoring the asterisk should ignore the extra parameter too, my bad. I should be able to fix that tomorrow.
c. Is there any workaround I miss which may give me the same expected result of providing say "%*s, width, charPtr" ? (I have 'width' and a non-null-terminated char pointer and need to construct the correct string from them without doing unnecessary copying...)
hmm, I could see a workaround like : int n= 10; string fmt = str(format( escape(" blabla %*d"), n)); format(fmt, 20); where the escape function escapes the % characters, and changes the asterisk into a %d : " blabla %%%dd" which will lead to fmt be : " blabla %10d" writing such an escape function shouldnt be too hard. 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. -- Samuel
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
participants (4)
-
Barak Simon -
Caleb Epstein -
Miro Jurisic -
Samuel Krempp