Re: retain and autorelease
Re: retain and autorelease
- Subject: Re: retain and autorelease
- From: Shawn Erickson <email@hidden>
- Date: Thu, 13 Nov 2003 15:29:48 -0800
On Nov 12, 2003, at 7:25 PM, Darwin Zins wrote:
When I do this:
ABPerson * newMacABEntry;
newMacABEntry = (ABPerson *) [_macAddressBook recordForUniqueId:
abID ];
Should I then do: [newMacABEntry retain]; and when I am done with it
[newMacABEntry autorelease];
It depends on what you are doing. In general if you are not using the
entry outside of the method you are currently in then you need not
retain it. It will remain for your use while inside of your method,
assuming you (or possibly someone else) do nothing to get it released
earlier. If you are worried that it could get release out from under
you then retain it (or retain and autorelease it in a pool that you
know the life time of).
If you need to hold on to the entry for periods of time longer then the
current method it is wise to retain it or possibly even copy it,
depending on you needs. If your are storing it in a member variable try
to put the retain/release/etc. logic in a set method don't have it
sprinkled throughout your code.
When done with it release it. You really don't need to use autorelease
in this case, you don't need to have a "delayed" release.
The book I am reading seems to say this as a rule of thumb, I am
wondering if this applies in this specific instance.
It depends on what you are doing...
I personally seldom retain something inside of method if I get it
handed to me by methods I call. I know when the containing autorelease
pool will be dealloced (not while in my method) and hence a release
sent to object I am using. The dealloc of the current pool usually
happens at the end of current event loop (unless you are dealing with
nested autorelease pools, likely ones that you have created).
If I am storing a reference to the object in a class member or instance
member I make sure to retain or copy it depending on the object
involved (is the object mutable and if so does having it change itself
on me what I want or not).
So my rule of thumb is do what makes sense and what is needed... but
most importantly be sensible and consistent in what you do so that your
code is easy to follow, etc. Also the less code (fewer retains and
release pairs, etc.) you have the easier it can be to debug and manage
in the long run.
I do suggest reading at least 2 different books on Cocoa/Objective-C by
different authors (in addition to the docs provided by Apple). By doing
so you can better ascertain what is from authors style and preference
compared to what is needed or why it may be done.
-Shawn
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.