Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!sdd.hp.com!mips!pacbell.com!pacbell!osc!tma From: tma@osc.COM (Tim Atkins) Newsgroups: comp.lang.c++ Subject: Re: Smart pointers and stupid people (was: garbage collection...) Message-ID: <4127@osc.COM> Date: 4 Jan 91 21:53:34 GMT References: <1990Dec20.045909.7681@rice.edu> <3071@lupine.NCD.COM> <4114@osc.COM> <4120@osc.COM> Reply-To: tma@osc.UUCP (Tim Atkins) Distribution: comp Organization: Versant Object Technology, Menlo Park, CA Lines: 52 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >> [ old exchange on smart-pointers not helping with object movement deleted] > >An off-the-cuff C++ approach to handling objects that may be garbage collected >and the pointers that point to them: > >1. The garbage collection routines (GC) would have full knowledge of the type >of objects that can be garbage collected, how they would be moved, and how to >clean up pointers to those objects. This implies that the "direct" pointers >to garbage collected objects are in a "well-known" place (PtrList). > >2. These "direct" pointers can, therefore, be allocated as an object is >created and put in the list in an indexable fashion for the "smart" pointers >to reference. There should only be one static list of these pointers so that >the GC can find them when its needs to do some shuffling. This totally misses the point it seems to me. The point is that regardless of what clever contortions one goes through on the C++ end there is absolutely no way at all to control the C intermediate code and/or object code that gets generated. The object code when run will most definitely create and use direct pointers to objects in an uncontrolled fashion. The challenge of moving C++ objects at will is to find and update these pointers. As the architecture is not tagged it is in principle impossible to do a simple scan and distinquish pointers from other memory words with the same pattern. Nor will knowing what the structure of objects is in the garbage collector solve all the problems as it will not handle any temporary variables set up by the compilers or copies of pointers setting around in registers. > >4. When GC decides to move an object, it uses the old address to index >(somehow) into the static list of pointers and replaces that address with the >new address of the object. GC should only move entire objects. > >5. When a "smart" pointer needs to dereference the object it points to, it >uses its smart index to find the real address from the static pointer list. >This probably the definition of the overloaded "->" operator on the smart >pointer. > Hmmm. I think I see what you're getting at. One approach is to have all pointers have one level of indirection so a double dereferencing always happens. When an object moves only the interior pointer (quaranteed only one per object) changes and not the exterior ones. Only trouble is this still doesn't help with temp copies on the stack and register references. > [locking discussion removed ] So I still have to take the position that without going into the compiler business and most likely losing some C compatibility, it is not possible to provide a fool-proof object movement scheme in C++. - Tim