home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13025 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.3 KB
  1. Path: sparky!uunet!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.92Aug28192437@arolla.idiap.ch>
  6. Date: 28 Aug 92 23:24:37 GMT
  7. References: <DAVEG.92Aug20043156@synaptx.synaptics.com> <28623@vedge.UUCP>
  8. Sender: news@ai.mit.edu
  9. Reply-To: tmb@idiap.ch
  10. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  11.     Perceptive)
  12. Lines: 35
  13. In-reply-to: hendrik@vedge.UUCP's message of 27 Aug 92 18:33:04 GMT
  14.  
  15. In article <28623@vedge.UUCP> hendrik@vedge.UUCP (Hendrik Boom) writes:
  16.  
  17.    daveg@synaptics.com (Dave Gillespie) writes:
  18.    : I did; as far as I can tell, the GC has to call destructors, and it's
  19.  
  20.    One of my nightmares in a Lisp garbage collector is the destructor
  21.    from Hell that retrieves otherwise moribund objects and makes them
  22.    accessible again.  Do we have to do another garbage collection to see if
  23.    objects are really free?  And if they are, do we have to call
  24.    the destructor from hell again? and again? and again? and again?
  25.  
  26. Please do not confuse GC finalization with C++ destructors. The two
  27. concepts are very different. Finalization routines should be written
  28. specifically for the purpose of finalization; it would be wrong for
  29. the GC to call the destructor for finalization.
  30.  
  31. Most finalization routines are really error handlers. They detect that
  32. some object that should have been destroyed explicitly (e.g., a file
  33. descriptor, a window) somehow got lost; they can fix the problem (to
  34. allow your buggy program to continue running) and send out a bug
  35. report. But you should (almost) never rely on finalization to destroy
  36. such objects for you as a matter of course.
  37.  
  38. So, finalization is really something that most users won't have to
  39. deal with, and the usual finalization routine will be very simple and
  40. straightforward. Because they are used rarely and not for very
  41. complicated things, the finalization hooks do not need to be very
  42. "user friendly" and might impose some restrictions on what you can do
  43. (just like you can't call "new" from the "new_handler").
  44.  
  45. Yes, finalization (in particular, in a conservative GC) is
  46. non-trivial; Boehm posted a reference to a paper about finalization in
  47. a conservative GC maybe this week.  You may want to look it up.
  48.  
  49.                     Thomas.
  50.