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