home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12906 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.1 KB  |  47 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: <1992Aug26.121040.8995@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: <1992Aug25.183619.9541@microsoft.com>
  11. Date: Wed, 26 Aug 1992 12:10:40 GMT
  12. Lines: 33
  13.  
  14. In article 9541@microsoft.com, jimad@microsoft.com (Jim Adcock) writes:
  15. > In article <DAVEG.92Aug20022559@synaptx.synaptics.com> daveg@synaptics.com (Dave Gillespie) writes:
  16. > |Do you really think incremental or generational collectors are
  17. > |feasible in C++?  I've never looked in the guts of one of these
  18. > |collectors, but as I understand it they tend to depend on the
  19. > |ability to move data around, and other things that a C++ collector
  20. > |might not be able to get away with.  (C++'s use of pointers is so
  21. > |unrestricted that it's a minor miracle it's possible to do garbage
  22. > |collection at all...)
  23. > 
  24. > Generational GC is certainly feasible in C++.  In practice one needs compiler
  25. > support for the implied "smart pointers", so that programmers don't have
  26. > to remember to use special pointer syntax everywhere.
  27. > 
  28. > C++ needs to support moveable objects in any case, in order to handled
  29. > ODBMS, persistence, locality of reference, etc.  If you ever have done
  30. > store/restore of objects from moveable store,  you've had to handle the
  31. > problem of moveable objects.  This is a standard programming problem not
  32. > well handled by current C++.  It needs compiler support.  Immovable object
  33. > GC schemes do not solve this problem -- they simply leave it to someone else
  34. > to solve.
  35.  
  36. I believe Apples C++ supports moveable objects. If I am correct pointers in this
  37. C++ are really pointers to handles which in their turn points to the objects
  38. current location. This would imply that each dereference in user code p->x
  39. would be translated by the compiler into (*p)->x.
  40.  
  41. Does anybody know if Apple's C++ works this way? If so, how do they handle
  42. pointers to objects on the stack.
  43.  
  44. /jonas
  45.  
  46.  
  47.