home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12656 < prev    next >
Encoding:
Text File  |  1992-08-20  |  1.9 KB  |  44 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!decwrl!parc!boehm
  3. From: boehm@parc.xerox.com (Hans Boehm)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <boehm.714327964@siria>
  6. Sender: news@parc.xerox.com
  7. Organization: Xerox PARC
  8. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <DAVEG.92Aug17231725@synaptx.synaptics.com>     <1992Aug19.180252.12942@mole-end.matawan.nj.us>     <DAVEG.92Aug20043156@synaptx.synaptics.com> <TMB.92Aug20143223@arolla.idiap.ch>
  9. Date: 20 Aug 92 16:26:04 GMT
  10. Lines: 32
  11.  
  12. tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  13. >I think the answer is simpler than that. Delete should continue to
  14. >work as it does (including returning memory to the system).
  15.  
  16. >In addition to that, there may be facilities to allow the programmer
  17. >to specify finalization of heap objects that are about to be collected
  18. >but have not been "deleted". Such a facility would not require any
  19. >language changes; something like "gc_set_finalization_hook(void*,void
  20. >(*f)(void*))" might do the trick. Some people may prefer to use such a
  21. >facility simply to detect memory leaks in existing programs, while
  22. >others might want to use it, for example, to release external
  23. >resources.
  24.  
  25. Technical point:
  26. There are some important issues related to the order in which
  27. objects get finalized by the collector.  If your program drops both an
  28. IO buffer and a corresponding file descriptor, the IO buffer needs to
  29. get finalized first, so that its contents can still be flushed.
  30. Typically finalization proceeds in topological order.  This means cycles
  31. become a problem.  The new version of our stand-alone collector in
  32.  
  33. parcftp.xerox.com:~ftp/pub/russell/gc.tar.Z
  34.  
  35. has one proposed (and still controversial) way of handling this.
  36.  
  37. (The current version of this collector has some known bugs, which you
  38. you may or may not notice.  It will be replaced by version 2.2 shortly.
  39. The finalization interface is not expected to change.)
  40.  
  41. Hans-J. Boehm
  42. (boehm@parc.xerox.com)
  43.  
  44.