home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12417 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.4 KB  |  51 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: <1992Aug17.123852.14232@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: <1992Aug16.052233.23166@ucc.su.OZ.AU> <1992Aug17.074855.24336@ericsson.se>
  10. Date: Mon, 17 Aug 1992 12:38:52 GMT
  11. Lines: 38
  12.  
  13. In article <1992Aug17.074855.24336@ericsson.se> jonas@beppe.ericsson.se writes:
  14. >In article 23166@ucc.su.OZ.AU, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  15. >> In article <1992Aug15.005542.3104@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
  16. >> >
  17. >> >Reference counting suffers serious drawbacks:
  18. >> >
  19. >> >1. It can't handle cyclic data structures
  20. >> >
  21. >> >2. It is one of the most inefficient forms of garbage collection known to man.
  22. >> >
  23. >> >The main reason I'm pushing for true garbage collection is that I consider
  24. >> >reference counting (which I already have) to be an unacceptably poor solution.
  25. >> 
  26. >>     Mm. Reference counting used to implement 'write on demand' in
  27. >> copy contructors is supposedly inefficient. But this is not at all
  28. >> the same as reference counting for garbage collection. In copy contructors,
  29. >> you have to check the reference count before each write operation,
  30. >> and if its not 1, clone off a copy of the object. Thats slow.
  31. >> 
  32. >>     But for GC you only have to increment the reference count
  33. >> when you take the address of the object to form a GC pointer,
  34. >> decrement it when the pointer is destroyed, and destroy the 
  35. >> object when the count goes to 0. That doesn't seem to be so slow
  36. >> to me: please correct me if I'm wrong.
  37. >
  38. >Wouldn't even a GC scheme have to create a copy of the object if the pointer was
  39. >used for non-const operations on the object? The advantage with implementing
  40. >GC pointers as separate constructs is that the programmer can decide when he
  41. >wants stucture sharing and whe he does not.
  42. >
  43.     GC pointers ought to behave like ordinary ones. When you
  44. copy a pointer you share the object.
  45.  
  46. -- 
  47. ;----------------------------------------------------------------------
  48.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  49.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  50. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  51.