On Sat, Jun 7, 2008 at 10:31 AM, Hamish Allan <[EMAIL PROTECTED]> wrote: > On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]> wrote: > >> The business about scanning the stack is essentially an >> implementation detail; the promise that is being made is that objects >> which you're still pointing to won't go away. > > We're just interpreting this promise differently. To my mind, while > the variable is still in scope, I *do* have a pointer to the object. > It is available for my use until the end of that scope. The fact that > I don't actually make use of it, and the optimising compiler thinks > I'm done with it: *that*'s an implementation detail.
This is pretty nitpicky. If it's in scope but you don't use it, then it doesn't matter. Kind of like a Zen koan: if an object is collected in the forest but nobody is pointing to it anymore, does it make a sound? Objects stay live for as long as you reference them, period. This is what the collector guarantees and this is what the real-world behavior is. The problem occurs when you try to reference their contents after you stop referencing the objects themselves. The documentation says nothing about scope, it talks about the stack. The stack is already an implementation detail, so if you're going to examine that promise then you absolutely need to examine those implementation details. >> How would it be less straightforward? If it returned collected memory >> then everything will Just Work for the common case of using the >> pointer on the stack. You would also have the additional convenience >> of being able to safely store the returned pointer in a __strong heap >> variable, something which you simply cannot do under non-GC rules at >> all. Looks like there are only improvements to me, where is the >> problem? > > I agree with you that if it returned collected memory, it would be > more powerful than under retain/release/autorelease. But power and > straightforwardness do not always go hand in hand ;) Hmm, you didn't answer my question though. Where exactly is the problem? For the case where the old-style rules also work, it would be precisely as straightforward. (In case your objection is with the __strong qualifier, note that you would not need that for a local variable, only for instance variables.) >> It *does* do this. The error is not in the GC, but rather in the >> assumption that "declared in the current scope" is equivalent to "is >> on the stack frame" > > Again, I see that as an implementation detail. From the documentation: > > "The root set is comprised of all objects reachable from root objects > and all possible references found by examining the call stacks of > every Cocoa thread." > > Given that the programmer cannot possibly know the state of the call > stack any other way than by considering normal variable scoping rules, > either it's meaningless to consider any variable on the stack as a > root object, or the compiler needs to guarantee equivalence between > them. I disagree. Since the programmer cannot possibly know the state of the call stack in any other way than by knowing that the compiler must keep references to objects right up to the point where those objects are no longer used, he must not make any assumption as to the lifetime of those objects beyond that point. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
