Re: ARC issue
Re: ARC issue
- Subject: Re: ARC issue
- From: Ken Thomases <email@hidden>
- Date: Wed, 07 Nov 2012 08:54:32 -0600
On Nov 7, 2012, at 8:33 AM, Andreas Grosam wrote:
> On 07.11.2012, at 14:50, Ken Thomases wrote:
>
>> This seems like a problem with ARC. Ideally, the compiler would understand not just that "error" is __autoreleasing but would understand something about its "autorelease scope". That is, it needs to survive to the caller's scope and so it needs to survive the @autoreleasepool block, so the compiler should retain it in the block and autorelease it outside.
> This is actually what I was hoping the compiler would understand - that the autoreleasing object would be assigned to those autorelease pool which is active at the time where the autoreleasing object has been defined (that is, the parent pool of the pool defined within fetchUser).
Well, I would not expect the compiler to understand what autorelease pool an object should be assigned to. That's not how autorelease pools work and it's also not in the nature of ARC. ARC concerns itself only with one function, method, or block at a time. Not coincidentally, that's also how Cocoa's manual memory management scheme was designed: the developer should only need to concern him- or herself with local correctness and be confident that global correctness will emerge from that.
I merely think that ARC should know that the __autoreleasing variable has a scope which exceeds the @autoreleasepool block in which it was assigned a value and do a retain/release at the exit of the @autoreleasepool block to make it survive at least until it goes out of scope.
> Otherwise, at least, the compiler should issue a warning about the implicit conversion from __strong to __autoreleased via a temporary.
I don't think that would be helpful. That conversion is not the source of the problem. What would you change about the call site in response to such a warning?
> The current behavior makes using output params difficult, especially if they are passed through a number of methods - possibly one that wraps code in an autorelease pool.
Agreed.
>> That said, I think the solution may be to declare a local, implicitly strong NSError pointer at the same scope as "user", use that within the @autoreleasepool block, and then assign from that to the output parameter, if it's non-NULL, outside of the block.
> I think I go with this workaround.
>
> Thank you all!
You're welcome.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden