On Aug 1, 2009, at 1:42 AM, Jerry Krinock wrote:
So I decided to -retainArguments, and presumed that this meant I was supposed to release the target and arguments when I was done with them.
As you've discovered, no, you're not supposed to do that. You have not retained the target and arguments. You have told the NSInvocation to do so, and it then has responsibility for releasing them.
But I thought it was odd that the documentation did not say so explicitly, so I did a little experiment, and learned that - retainArguments also adds them to the autorelease pool!
Whether they are released or autoreleased is an implementation detail on which you shouldn't rely. And, to be clear, -retainArguments doesn't "[add] them to the autorelease pool". That would imply they are autoreleased by the time -retainArguments returns, which would defeat the whole purpose. But asking the NSInvocation to take ownership of its arguments does cause it to later release them, yes.
Presumably (I hope) this happens when and in the thread where the invocation is invoked.
Not when nor where the invocation is invoked. When and where the invocation is ultimately deallocated, just like with typical objects which own other objects. Among other reasons, invocations can be invoked multiple times, so it definitely can't be when it's invoked.
The code and results are below. Whether -retainArguments is commented out or not, the target (Target) and the argument (StringWrapper) both get deallocced just the same. If - retainArguments is commented out, the final NSLog() does cause a crash, but that is expected since in this case the target and argument have not been placed in the autorelease pool by the action of -retainArguments.
My interpretation of your results is that neither the target nor argument are being autoreleased. Rather, the NSInvocation is autoreleased as is fairly common for objects obtained through convenience constructors. It, in turn, just directly owns the target and argument (because you told it to with -retainArguments) and releases them as it is being deallocated.
Regards, Ken _______________________________________________ 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 arch...@mail-archive.com
