home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12615 < prev    next >
Encoding:
Text File  |  1992-08-19  |  2.0 KB  |  47 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: <1992Aug19.180252.12942@mole-end.matawan.nj.us>
  6. Summary: Reliability
  7. Organization: :
  8. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <DAVEG.92Aug17231725@synaptx.synaptics.com>
  9. Date: Wed, 19 Aug 1992 18:02:52 GMT
  10. Lines: 35
  11.  
  12. In article <DAVEG.92Aug17231725@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
  13. > In article <1992Aug16.075804.27511@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
  14.  
  15. > Suppose you have an existing C++ program.  Suppose there is an object
  16. > in that program's memory that has been allocated and which no longer
  17. > has any references to it of any sort, and which has not been deleted
  18. > explicitly.  Most people would consider that a bug; ...  your program
  19. > is not planning on deleting the object because it no longer has any
  20. > references to it.  Is there really so much harm in allowing the C++
  21. > runtime system to delete the object in that circumstance?  If you left
  22. > the object dangling and it had a destructor that had a noticeable
  23. > effect on the rest of the program, you almost certainly had a bug anyhow.
  24.  
  25.     Is there really so much harm in allowing the C++ runtime
  26.     system to delete the object in that circumstance?
  27.  
  28. You've answered your own question in the negative.  If the destructor
  29. has an effect on the program's output, and it is accidentally called
  30. by the GC instead of by its proper deletion, the program's output will
  31. depend on the exact properties of the GC system and the exact sequencing
  32. of internal states of the program and of the program's runtime internals'
  33. states.  It might work correctly by accident in testing, and fail
  34. disastrously in service.
  35.  
  36. Allowing GC to operate destructors is not safe.
  37.  
  38. Not allowing GC to operate destructors does not suit C++'s model of
  39. execution.
  40.  
  41. Think about it.
  42. -- 
  43.  (This man's opinions are his own.)
  44.  From mole-end                Mark Terribile
  45.  
  46.  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
  47.