home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12409 < prev    next >
Encoding:
Text File  |  1992-08-16  |  2.2 KB  |  54 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!sunic!ericom!falcon!jonas
  3. From: jonas@beppe.ericsson.se (Jonas Nygren)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <1992Aug17.074855.24336@ericsson.se>
  6. Sender: news@ericsson.se
  7. Nntp-Posting-Host: falcon.ericsson.se
  8. Reply-To: jonas@beppe.ericsson.se
  9. Organization: Ericsson Telecom AB
  10. References: <1992Aug16.052233.23166@ucc.su.OZ.AU>
  11. Date: Mon, 17 Aug 1992 07:48:55 GMT
  12. Lines: 40
  13.  
  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.  
  44. > -- 
  45. > ;----------------------------------------------------------------------
  46. >         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  47. >     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  48. > ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  49.  
  50.  
  51. /jonas
  52.  
  53.  
  54.