Replacement for snprintf

berni44 dlang at d-ecke.de
Wed Oct 30 13:44:52 UTC 2019


In PR 7222 [1] Robert Schadek suggested replacing the call to 
snprinf in std.format with an own method written in D. During the 
last days I took a deeper look into this and meanwhile I've got a 
function that works for floats (and probably also doubles, but I 
havn't tested that yet and it should also work with reals if 
ucent would be available; without ucent I need a workaround for 
real or fall back to BigInt).

I only implemented f qualifier yet, but it shouldn't be difficult 
to add e and g qualifiers and the uppercase versions. Also some 
work needs to be done, to implement the flags (-,+,0,<space>,#), 
but again, I think, this will not be very difficult. 
Unfortunately I'll be busy with some other (non-D) stuff for some 
time. I'll probably continue work on this someday in november.

I checked correctness for floats by comparing to the result of 
snprintf for about 1% of all numbers (I will do that for all, 
before filing an PR though). The only difference are rounding 
issues, when the number is exactly between two adjacent ways of 
displaying. The implementation of snprintf on my computer always 
rounds towards zero while mine rounds in the opposite direction. 
(E.g. 0.125 rounded to two digits is 0.13 in my implementation 
while it's 0.12 in snprintfs implementation) I doubt, that 
different implementations of printf-variants are all identical in 
this regard.

I also compared the speed of both implementations. They are 
generally in the same order of magnitude (600-2800ns per number, 
depending on precision and number). On average my implementation 
is slightly faster. For numbers close to 0 the snprintf 
implementation is faster (I wasn't able to follow the algorithm 
they use), especially if the desired precision is large (I'll try 
to improve this, because it might get a real problem for reals). 
For all other numbers my current implementation wins by a more or 
less small margin.

[1] 
https://github.com/dlang/phobos/pull/7222#issuecomment-544909188


More information about the Digitalmars-d mailing list