home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v3 / text0018.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  1.5 KB
  1. Date: Thu, 14 Nov 85 17:21:36 pst
  2. From: saber!msc@ihnp4.uucp (Mark Callow)
  3.  
  4. > From: Kee Hinckley <harvard!wanginst!apollo!nazgul>
  5. > 
  6. > In article <3430@ut-sally.UUCP> you write:
  7. > > Date: 06 Oct 85 18:36:07 +1000 (Sun)
  8. > > >From: Robert Elz <munnari!kre@seismo.CSS.GOV>
  9. > ...
  10. > > I suggest deleting all of the constants, and instead specifying
  11. > > a library routine, which when handed a name defined in <limits.h>
  12. > > will return the associated constant.
  13. > > 
  14. > 
  15. > One problem with this is that a piece of code may want to #if off of
  16. > particular constants.  For instance, if I discover that the amount
  17. > of memory I have is too small, and I don't have virtual memory then
  18. > I might want to use temporary files.
  19. You can do this just as well with an if statement at runtime.  Then
  20. if someone decides to add more memory to their machine they don't
  21. have to recompile their world to take advantage of it.
  22.  
  23. > ...but it would not work out nearly as well if I had to
  24. > make that kind of decision at runtime.
  25. Why not?  The penalty is a small increase in the size of the
  26. binary.
  27.  
  28. limits.h and all similar kinds of wired-in constants are the pits.
  29. What happens in a network environment?  Do your servers have one
  30. copy of the program for each client configuration?  Of course not.
  31. What does a computer manufacturer do?  Have a different software
  32. release for each system configuration?  Of course not.  You
  33. either end up in the least common denominator trap or you ignore
  34. limits.h and implement the library function suggested by kre.
  35.  
  36. Volume-Number: Volume 3, Number 19
  37.  
  38.