Path: utzoo!censor!comspec!humvax!becker!ncrcan!attcan!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++ Subject: Re: Smart pointers and stupid people (was: garbage collection...) Message-ID: Date: 7 Jan 91 18:57:09 GMT References: <1990Dec20.045909.7681@rice.edu> <3071@lupine.NCD.COM> <4114@osc.COM> <4120@osc.COM> <4127@osc.COM> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California Lines: 53 In-reply-to: tma@osc.COM's message of 4 Jan 91 21:53:34 GMT X-Posting-Software: GNUS 3.12 [ NNTP-based News Reader for GNU Emacs ] >>>>> On 4 Jan 91 21:53:34 GMT, tma@osc.COM (Tim Atkins) said: Tim> In article Tim> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: David> An off-the-cuff C++ approach to handling objects that may be garbage David> collected and the pointers that point to them: David> ... Tim> This totally misses the point it seems to me. The point is that Tim> regardless of what clever contortions one goes through on the C++ end Tim> there is absolutely no way at all to control the C intermediate code Tim> and/or object code that gets generated. I've never really examined the code that C++ generates, but I would think that the C code could only do what the C++ code specifies at the time that it specifies it. That is to say that if the C++ code does (A, B, C), then the generated C code will do (A+, B+, C+) (where the '+' is possible extra code to fill in the intentions of the C++ statement as C understands them). Therefore, if B is doing something in an uncontrolled fashion, then A and C could be used to control B and the generated C code would follow suit. Is this a wrong impression of what C++ generates? David> 4. When GC decides to move an object, it uses the old address to index David> (somehow) into the static list of pointers and replaces that address David> with the new address of the object. GC should only move entire David> objects. David> 5. When a "smart" pointer needs to dereference the object it points David> to, it uses its smart index to find the real address from the static David> pointer list. This probably the definition of the overloaded "->" David> operator on the smart pointer. Tim> Hmmm. I think I see what you're getting at. One approach is to have all Tim> pointers have one level of indirection so a double dereferencing always Tim> happens. When an object moves only the interior pointer (quaranteed only Tim> one per object) changes and not the exterior ones. Only trouble is this Tim> still doesn't help with temp copies on the stack and register references. Isn't that what locking is for (assuming my above statement is correct)? In particular, if there are temp copies of the pointers on the stack or register references, who cares? Once outside the lock protocol, these vestiges will never be used again (they may be REINITIALIZED when reentering the lock protocol, though). -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"