home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3495 < prev    next >
Encoding:
Text File  |  1992-11-05  |  2.0 KB  |  44 lines
  1. Newsgroups: comp.lang.misc
  2. Path: sparky!uunet!pipex!warwick!nott-cs!piaggio!anw
  3. From: anw@maths.nott.ac.uk (Dr A. N. Walker)
  4. Subject: Re: Pointers
  5. Message-ID: <1992Nov5.153459.22708@maths.nott.ac.uk>
  6. Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker)
  7. Organization: Maths Dept., Nott'm Univ., UK.
  8. References: <1992Nov2.083810.1652@syacus.acus.oz.au> <Bx3BsH.I0J@mentor.cc.purdue.edu> <1992Nov3.130634.26112@rdg.dec.com> <1992Nov4.031026.23624@linus.mitre.org>
  9. Date: Thu, 5 Nov 1992 15:34:59 GMT
  10. Lines: 32
  11.  
  12. In article <1992Nov4.031026.23624@linus.mitre.org>
  13. crawford@boole.mitre.org (Randy Crawford) writes:
  14. >The nice thing about C's low level programming support is that you
  15. >don't have to tolerate the imposition and girth of a garbage collector
  16. >(something that belongs in a library anyway).  If you really want one,
  17. >once again, C will let you roll your own.
  18.  
  19.     No it won't.  There is no way [provided by C -- an individual
  20. compiler or system may add one, of course] of finding out whether some
  21. object is being pointed at, so there is no way of determining which
  22. objects are "dead".  There is no way of "compacting" live storage, and
  23. shifting all pointers to correspond.  For specific applications, you can
  24. rig up versions of "malloc" and "free" to do this, but not in general.
  25.  
  26.     In languages that *do* provide proper garbage collection, it
  27. is usually included only if your program includes constructs that
  28. might cause it to be invoked -- in C terms, it might be a library
  29. procedure that was called by "malloc" -- which gets round your objection
  30. to its "imposition and girth" [whatever that means!].
  31.  
  32. >If you want run-time error checking, then C is the wrong choice of
  33. >programming language for a lot of better reasons than array bounds
  34. >checking.
  35.  
  36.     Why?  I quite like C, and it wouldn't make it any worse as a
  37. language if there was at least a compiler option [as indeed there is
  38. for *some* compilers] for array bound checking, pointer validity
  39. checking, etc.
  40.  
  41. -- 
  42. Andy Walker, Maths Dept., Nott'm Univ., UK.
  43. anw@maths.nott.ac.uk
  44.