Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!ucsd!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: <4174@osc.COM> Date: 26 Jan 91 08:47:22 GMT References: <4127@osc.COM> <3344@lupine.NCD.COM> Reply-To: tma@osc.UUCP (Tim Atkins) Distribution: comp Organization: Versant Object Technology, Menlo Park, CA Lines: 72 In article <3344@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >+>>>>> 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. >No. It isn't. I believe that you are correct. In short, I believe that >Tim's vague concerns about rogue pointers running rampage (without our >permission) in the (mysterious?) C code which is generated by cfront is >a non-issue. > >+In particular, if there are temp copies of the pointers on the stack or >+register references, who cares? > >Exactly. > I can scarcely believe that folks of your caliber can not seem to see the obvious problem for object movement that these supposedly innocent generated pointers create. Obviously, a dereference of a smart pointer MUST happen somewhere in the generated code for any real work to get done. Obviously, generated results can be and often are stored away by compiler generated code even without counting optimization for later use in any context where it can be determined by the compiler that any depended on values are constant in particular. Now, if I call something that causes the object to move, then these stored away pointers are now invalid. However, HOW DOES THE COMPILER know? I don't know of any way to make it know this strictly from the language end. True a compiler can be built that does makes this possible. On return from the movement causer the code can happily use the old pointer as, say the ultimate receiver of a mutation function. You now have updated the object's old location NOT the working object. This seems to me to obviously be a bug. Does this really make it clear enough what I'm getting at? I would prefer to stick to a general statement of the problem as it is always easy to finagle a particular example to where all works well. This can lead to false confidence that there is no real problem. However, consider the following simple minded example of where the problem might occur: void Foo::a( SmartB x, SmartC y){ something(x,y); somethingMore(x); this->doOther(); } Here if something and somethingMore take real pointers as they would if the were extern functions then obviously room for grief exists. If this problem is bypassed, then what if "something" causes a garbage collect in a compacting collector? Then the "this" is wrong and the last call will update the wrong location. This is not the best of examples and I'm sure you or other folks are creative enough to blow holes in it or least come up with exotic variations of how to do it right. BUT I think it does illustrate the sort of tangles that have to be dealt with. So far, none of the solutions that stop short of a compiler change will deal successfully with all such situations, in my opinion . If this problem can be easily dismissed then no one will be happier than I. But at least be so kind as to tell us what the solution is instead of merely making bald statements that no problem is there. - Tim Atkins