home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12380 < prev    next >
Encoding:
Text File  |  1992-08-15  |  2.6 KB  |  61 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <1992Aug15.154818.12396@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <DAVEG.92Aug13025629@synaptx.synaptics.com> <1992Aug14.021547.15215@news.mentorg.com>
  10. Date: Sat, 15 Aug 1992 15:48:18 GMT
  11. Lines: 48
  12.  
  13. In article <1992Aug14.021547.15215@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
  14. >
  15. >In article <DAVEG.92Aug13025629@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
  16. >
  17. >This would accord with existing C++ philosophy, but I don't see how
  18. >you could make a GC that's immune to dangling pointers. Anyone out
  19. >there know otherwise?
  20.  
  21.     GC objects would be immune to dangling GC pointers.
  22. If a GC pointer is rooted (exists non-circularly) then the object
  23. wont get deleted when you say 'delete'. The pointer gets
  24. zeroed out though.
  25.  
  26. >
  27. >|> What if you have virtual base classes, and there are only references
  28. >|> to the base part of an object?  The derived part of the object has
  29. >|> a pointer to the base part but not the other way around, so the
  30. >|> derived part might be collected in this case.  Can this ever be a
  31. >|> problem?
  32. >
  33. >I don't think so, but I don't know the mechanics of inheritance (and in
  34. >particular MI) well enough to say. Comments from those who know the
  35. >dirty details of inheritance welcome!
  36.  
  37.     This is a major problem. Specifically, if an exact object
  38. is GC, then all its accessible base classes must be too. INcluding
  39. the abstract ones. This will tend to partition programs into
  40. a GC part and a non-GC part. In particular, the GC mechanism
  41. must be able to 'downcast' from a GC objects base to the actual
  42. object like a virtual destructor can, and for the same reason.
  43.  
  44.     As far as I can see, all pointers to GC objects must
  45. be GC pointers. And all pointers INTO them too. Otherwise
  46. you can 'delete' via an ordinary pointer, and an ordinary
  47. pointer could dangle.
  48.  
  49.     This makes the GC kernel secure, and allows outwards
  50. references to non-GC objects. All inwards references have to be
  51. GC pointers.
  52.  
  53.     In this system it is imperative that GC pointers in
  54. ordinary objects be properly destroyed.
  55.  
  56. -- 
  57. ;----------------------------------------------------------------------
  58.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  59.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  60. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  61.