Source for "integer to ascii" and multiple file search-n-replace
leland.f.derbenwick
lfd at cbnewsm.att.com
Wed Nov 28 09:41:11 AEST 1990
In article <1990Nov26.192218.29782 at athena.mit.edu>, scs at adam.mit.edu (Steve Summit) writes:
> In article <324 at cti1.UUCP> mpledger at cti1.UUCP (Mark Pledger) writes:
> >Maybe nobody is reading my question, but everyone keeps mailing me answers
> >using sprintf() which is actually what I don't want.
...
> Sprintf simply is the recommended function, and it is "fast
> enough" in the vast majority of applications. It is the rare
> program that can be significantly sped up with a special-purpose
> itoa-type routine, and you gave us no indication of why your
> program might be one of them.
...
I believe very strongly in coding systems to have good performance.
But here's a rule of thumb for optimizing code:
If you can't say very clearly _why_ you need a faster version
of a particular routine, then you probably don't need it.
In the cases I can think of (implementation on bare hardware, with no
sprintf available; or absolutely performance-critical and the overall
algorithm can't be improved instead), knowing _why_ you need it would
imply enough knowledge to be able to code it yourself, easily. (Well,
maybe if it were a homework assignment and the professor didn't allow
you to use sprintf! :-) Anyway, if it's truly performance-critical,
you probably need a function tuned to the application: fixed-length
strings, or particular distributions of input, or only unsigned, or if
all else fails maybe even assembly language. So generic code probably
wouldn't do.
-- Speaking strictly for myself,
-- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ
-- lfd at cbnewsm.ATT.COM or <wherever>!att!cbnewsm!lfd
More information about the Comp.lang.c
mailing list