home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / mac / programm / 15144 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  1.5 KB
  1. Path: sparky!uunet!stanford.edu!rutgers!cmcl2!panix!spencer
  2. From: spencer@panix.com (David Spencer)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: printf and scanf (was: THINK C linker makes me sad)
  5. Message-ID: <1992Sep8.143032.14302@panix.com>
  6. Date: 8 Sep 92 14:30:32 GMT
  7. References: <fdrny7c.howard@netcom.com>
  8. Distribution: usa
  9. Organization: PANIX Public Access Unix, NYC
  10. Lines: 27
  11.  
  12. howard@netcom.com (Howard Berkey) writes of THINK C:
  13.  
  14. >So I was writing this really small, simple app. (a mac version of xclock,
  15. >just for fun.)  It was only 3k.  Then I added a call to sprintf().  It 
  16. >exploded the program to 22k.
  17.  
  18. Sic semper printf ["Thus be it always to printf", for the history- or
  19. latin-impaired].
  20.  
  21. The printf functions are complex; they do a lot. The scanf functions
  22. are even worse. In any environment, they will explode code.
  23.  
  24. They are also hard for the implementer to get right. THINK C, so far
  25. as I can tell, is OK. My $750 [list price] dos compiler/library has a
  26. printf that botches unsigned longs.
  27.  
  28. Moreover, except for simple uses (for which putc or puts are
  29. adequate), they are hard for the user to get right.
  30.  
  31. If possible, avoid printf and scanf (and cousins). Don't pay the
  32. overhead of all that formatting power, unless you need it. Use putc
  33. and puts (and getc and gets). If you know the output format, it's
  34. often easier (and certainly smaller) to write a custom formatter (no
  35. flames, please; I've just re-read Henry Spencer's _How to Steal Code_
  36. in penance for that statement...)
  37.  
  38. dhs   spencer@panix.com
  39.