Hi Marcus, all, I finally started on these additions and noticed a couple things...
1) Using %.4e, for example, only gives 3 decimal places instead of 4 -- I assume I can/should fix that? 2) I realized "precision" isn't supported with d/u/o/x etc., just width+padding. Precision could be used for minimum *number* width (left-pad with 0s if needed) *and* have a minimum *field* width with non-0 padding. So should I add "precision" support for the aforementioned specifiers? 3) Is it OK to modify the parameters of the php_sprintf_* functions? It's necessary in order to add some of these things. Also, could the _appendint and _appenduint functions be combined? They're mostly duplicate code, and doing so would save a "char numbuf[500]" array... Thanks, Matt ----- Original Message ----- From: "Marcus Boerger" Sent: Friday, July 21, 2006 > Hello Matt, > > sounds good then, keep going. > > best regards > marcus > > Friday, July 21, 2006, 10:08:19 AM, you wrote: > > > Hi Marcus, > > > ----- Original Message ----- > > From: "Marcus Boerger" > > Sent: Thursday, July 20, 2006 2:21 PM > > Subject: Re: [PHP-DEV] [v][sf]printf additions (#, E, g, G) > > > >> Hello Matt, > >> > >> Thursday, July 20, 2006, 2:20:46 PM, you wrote: > >> > >> > Hi, > >> > >> > I've wished there was a *printf() float specifier that wouldn't include > >> > trailing zeros/point, as simply converting to string (echo, %s, etc.) > > can > >> > result in scientific notation, which I *don't* want (%g in > >> > convert_to_string()). The only other way that would result in what I > > want > >> > is number_format() with my "no-extra-zeros option" patch. ;-) So I was > >> > originally looking for how to NOT pad %f to the specified precision, > > then I > >> > thought why not add more of the stuff from C? (And I see it's marked > > "not > >> > done" in formatted_print.c.) > >> > >> > Can/should I go ahead and add support for the # flag/specifier, g/G, and > > E > >> > (the missing compliment to e)? Make everything work like C, except # > > used > >> > with f/F, which would mean "remove trailing 0's/point" -- as C's > > behavior > >> > with # and f (add point even when precision=0?) can be done in PHP. (I > >> > assume C's is for when precision is specified with * + parameter?) > >> > >> Having more conversion specifiers here won't hurt. If it can be done > >> in a way compatible to other languages especially like C it should be > >> done in that way. If PHP has already closed the way by choosing opposite > >> defaults the opposite should everntually also work. > > > Sorry, not sure what you mean in the last sentence as far as the additions > > I'm asking about. I agree about compatibility with C's specifiers, but > > PHP's *printf() has things that C's doesn't (%b; alternate padding > > specifier) and vice versa (PHP's doesn't support "*" width/precision -- nor > > does it need to; also no %n). That's why I thought it would be OK to let # > > with f/F mean no trailing 0's. > > > Other than that, g/G would, of course, be new. Unless it's not needed if 1) > > my "alternate form" %f idea is added, or 2) its precision would confuse > > users since it means "number of significant digits" with g/G, rather than > > decimal places. > > > # with e/E would include the decimal point even if precision=0 > > # with g/G *wouldn't* strip trailing 0's > > # with o would include "0" prefix with non-zero result > > # with x/X would include "0x"/"0X" prefix with non-zero result > > > All like C AFAIK, again except %#.3f, for example, wouldn't have trailing > > zeros/point. As you can probably tell, I don't like extra 0's unless > > there's a *need* to always have the same width (same idea with > > number_format()). :-) I'm sure other PHP users feel the same way and would > > like this alternate %f form, even if no other language has it! > > >> Best regards, > >> Marcus > > > Thanks for the reply, > > Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
