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. > 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 ;) > 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. Hamish _______________________________________________ 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]
