home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12634 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.4 KB
  1. Path: sparky!uunet!usc!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <TMB.92Aug20143223@arolla.idiap.ch>
  6. Date: 20 Aug 92 18:32:23 GMT
  7. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <DAVEG.92Aug17231725@synaptx.synaptics.com>
  8.     <1992Aug19.180252.12942@mole-end.matawan.nj.us>
  9.     <DAVEG.92Aug20043156@synaptx.synaptics.com>
  10. Sender: news@ai.mit.edu
  11. Reply-To: tmb@idiap.ch
  12. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  13.     Perceptive)
  14. Lines: 33
  15. In-reply-to: daveg@synaptics.com's message of 20 Aug 92 11:31:56 GMT
  16.  
  17. In article <DAVEG.92Aug20043156@synaptx.synaptics.com> daveg@synaptics.com (Dave Gillespie) writes:
  18.  
  19.    In article <1992Aug19.180252.12942@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
  20.  
  21.    > You've answered your own question in the negative.  If the destructor
  22.    > has an effect on the program's output, and it is accidentally called
  23.    > by the GC instead of by its proper deletion, the program's output will
  24.    > depend on the exact properties of the GC system and the exact sequencing
  25.    > of internal states of the program and of the program's runtime internals'
  26.    > states.  It might work correctly by accident in testing, and fail
  27.    > disastrously in service.
  28.  
  29.    Sorry, I didn't make myself clear.  I realize that allowing GC to call
  30.    a destructor would add one more case where destructors with side effects
  31.    could surprise the C++ programmer.  My question was, is that potential
  32.    for surprise enough to kill the idea of garbage collection in C++?
  33.  
  34.    My answer is no, it just means C++ programmers who use garbage collection
  35.    have to be a little careful about what they put in their destructors.
  36.  
  37. I think the answer is simpler than that. Delete should continue to
  38. work as it does (including returning memory to the system).
  39.  
  40. In addition to that, there may be facilities to allow the programmer
  41. to specify finalization of heap objects that are about to be collected
  42. but have not been "deleted". Such a facility would not require any
  43. language changes; something like "gc_set_finalization_hook(void*,void
  44. (*f)(void*))" might do the trick. Some people may prefer to use such a
  45. facility simply to detect memory leaks in existing programs, while
  46. others might want to use it, for example, to release external
  47. resources.
  48.  
  49.                     Thomas.
  50.