home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12896 < prev    next >
Encoding:
Text File  |  1992-08-25  |  1.5 KB  |  33 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <1992Aug25.183619.9541@microsoft.com>
  6. Date: 25 Aug 92 18:36:19 GMT
  7. Organization: Microsoft Corporation
  8. References: <DAVEG.92Aug17224359@synaptx.synaptics.com> <boehm.714158406@siria> <DAVEG.92Aug20022559@synaptx.synaptics.com>
  9. Lines: 22
  10.  
  11. In article <DAVEG.92Aug20022559@synaptx.synaptics.com> daveg@synaptics.com (Dave Gillespie) writes:
  12. |Do you really think incremental or generational collectors are
  13. |feasible in C++?  I've never looked in the guts of one of these
  14. |collectors, but as I understand it they tend to depend on the
  15. |ability to move data around, and other things that a C++ collector
  16. |might not be able to get away with.  (C++'s use of pointers is so
  17. |unrestricted that it's a minor miracle it's possible to do garbage
  18. |collection at all...)
  19.  
  20. Generational GC is certainly feasible in C++.  In practice one needs compiler
  21. support for the implied "smart pointers", so that programmers don't have
  22. to remember to use special pointer syntax everywhere.
  23.  
  24. C++ needs to support moveable objects in any case, in order to handled
  25. ODBMS, persistence, locality of reference, etc.  If you ever have done
  26. store/restore of objects from moveable store,  you've had to handle the
  27. problem of moveable objects.  This is a standard programming problem not
  28. well handled by current C++.  It needs compiler support.  Immovable object
  29. GC schemes do not solve this problem -- they simply leave it to someone else
  30. to solve.
  31.  
  32.  
  33.