home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12391 < prev    next >
Encoding:
Text File  |  1992-08-15  |  3.0 KB  |  62 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@mole-end.matawan.nj.us
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <1992Aug16.075804.27511@mole-end.matawan.nj.us>
  6. Organization: :
  7. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <TMB.92Aug14130323@arolla.idiap.ch>
  8. Date: Sun, 16 Aug 1992 07:58:04 GMT
  9. Lines: 51
  10.  
  11. In article <TMB.92Aug14130323@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  12. > In article <1992Aug14.021547.15215@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
  13.  
  14. >    In article <DAVEG.92Aug13025629@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
  15. >    |> Couldn't we get away with having a garbage collector that didn't
  16. >    |> need pointers to be declared `GC'?
  17.  
  18. >    I can't see that this is viable given the basic constraints on C++: among
  19. >    other things, those who don't want GC shouldn't have to suffer the hits.
  20. > 
  21. > What "hits"? In all the cases that I have looked at, the GC overhead
  22. > has been _smaller_ than the overhead of explicit memory management in
  23. > C++.  ...
  24.  
  25. > Based on my experience, I would turn your statement around and say:
  26. > "those of us who want GC shouldn't have to suffer the inefficiencies
  27. > of not having it".
  28.  
  29. The real problem with GC is that it is based on a particular model of
  30. how a programming language represents something.  That model states
  31. that the _value_ of something is all that matters; once the value
  32. disappears, the identity means nothing.  On the other hand, C++, with
  33. defined lifetimes for objects, declares that the object identity is
  34. part of the model of computation.
  35.  
  36. To put it differently, when does the destructor for a GC'd object get
  37. called?  What happens if the GC'd object's destructor makes a call that
  38. has an effect outside the system?  In other words, what happens to
  39. relationships between the objects in the system and the world outside?
  40.  
  41. A great deal of a program's information is stored in the relationships
  42. between things, and not just in their values.  A GC'able language has
  43. a certain semantic restriction: you will never use the actual object
  44. (i.e. object-in-memory as C and C++ define the word) identity to represent
  45. something.  If you have a reference to another object, it is because you
  46. are interested in the value stored there, not in the object identity
  47. itself.  Once the value is no longer accessible, the object identity is 
  48. worthless.
  49.  
  50. C++ doesn't make this assumption.  Some data structures that are written
  51. in C++ may, and GC may be suitable for those data structures.  But the
  52. suitability of those data structures to GC shouldn't be mistaken for
  53. the suitability of C++ for GC.  C++ doesn't assume or demand GC'able
  54. semantics in its representations.  In fact, it assumes _and_ demands
  55. semantics that are contrary to GC (management of object lifetime)--but
  56. it doesn't force these semantics on every representation.
  57. -- 
  58.  (This man's opinions are his own.)
  59.  From mole-end                Mark Terribile
  60.  
  61.  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
  62.