Re: Referencing an object after sending a release message to it
Re: Referencing an object after sending a release message to it
- Subject: Re: Referencing an object after sending a release message to it
- From: Thomas Wetmore <email@hidden>
- Date: Sat, 06 Aug 2011 19:57:06 -0400
It may look odd to use an object that has been just released, but there is nothing wrong in this case, and no assumptions are needed here. As soon as the object has been added to the array it has been safely retained on the same thread by well-understood and well-documented rules, and it should be released as soon thereafter as is practical. I too don't like the way this code feels, but moving the release to the end has no effect other than making some of us possibly feel good. For those who feel best when memory is released as soon as it is possible to do so, this code is fine. For however laudable it is to write comfortable code one must decide for oneself where to put the release.
What I found more odd about the example code was the idea that I would use a controller to create an object, and then immediately turn around and tell the controller to save the object it just created. Why not have the controller do that directly and return the object autoreleased? No memory management needed by the controller user.
On Aug 6, 2011, at 5:36 PM, Scott Ribe wrote:
> On Aug 6, 2011, at 3:06 PM, Jon Boone wrote:
>
>> Is it dangerous to send the release message to p right after adding it to the array? Should I put the release at the end of the method?
>
> You should release it when you're done with it. Granted, you can probably get away with it here, under a reasonable set of assumptions: employeeController actually retains it, rather than copying it, or just using it in the addObject method and not keeping a reference to it, and rearrangedObjects doesn't cause it to be released, and there's not some background thread that will modify employeeController and release it asynchronously.
>
> But it would be a terrible habit to get in to. (Note how many assumptions it relies on...)
_______________________________________________
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