Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!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: 4 Feb 91 04:18:46 GMT References: <4127@osc.COM> <3344@lupine.NCD.COM> <4174@osc.COM> Sender: news@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California Lines: 57 In-reply-to: tma@osc.COM's message of 26 Jan 91 08:47:22 GMT >>>>> On 26 Jan 91 08:47:22 GMT, tma@osc.COM (Tim Atkins) said: Tim> In article <3344@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: Ron> In article Ron> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: David> On 4 Jan 91 21:53:34 GMT, tma@osc.COM (Tim Atkins) said: 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. My quote is missing here and it is very important for the conversation. Basically, the assumption has been that generated code from C++ will not do anything outside of the sequential statements expressed in the C++ program. That is, if C++ says do A B C, then the generated code will do no more than A+ B+ C+ (none of B's behavior will be done after C). This means that B can be controlled by A and C. Ron> No. It isn't. I believe that you are correct. In short, I believe that Ron> Tim's vague concerns about rogue pointers running rampage (without our Ron> permission) in the (mysterious?) C code which is generated by cfront is a Ron> non-issue. David> In particular, if there are temp copies of the pointers on the stack or David> register references, who cares? Ron> Exactly. Tim> I can scarcely believe that folks of your caliber can not seem to see the Tim> obvious problem for object movement that these supposedly innocent Tim> generated pointers create. [... more on uncontrolled dereferences ...] The point of my statement above is that, if it is true (I believe it is, but I might be wrong), then controlled GC can be implemented safely with respect to C++ as easily as it might be implemented with respect to C. Controlled GC means that garbage collection can only occur on an object when the controls on the object allow it. Also, during the period where GC on an object is not allowed (call this the transaction period), all invoked references to the object must first recompute themselves at least the first time in the transaction period. With this design for GC, the key is to implement objects AND access to objects that obey this. The problem has been that the standard (dumb) dereferencing of pointers is not safe and, therefore, must be controlled (which means use them only when controls allow AND they have been computed as being correct). -- ==================================================================== 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!"