Re: Proper retain/release etiquette
Re: Proper retain/release etiquette
- Subject: Re: Proper retain/release etiquette
- From: Roarke Lynch <email@hidden>
- Date: Wed, 31 Dec 1969 20:26:21 -0500
On Monday, July 22, 2002, at 09:05 PM, Chris Anderson wrote:
1. If my code alloc's an object, it is implicitly retained by me and
must be
subsequently released. (Said another way, if I did [[[Foo alloc] init]
retain] I would have to release the object twice for it to deallocate.)
yes, init, copy and retain all increase an objects reference count
by one. It is good for any method (with the exception of your init and
dealloc methods) to have an equal count of (init, copy or mutableCopy,
retain) and (release, autorelease).
2. The right place to release contained objects is in the dealloc
method.
They should be released and then a [super dealloc] should be done.
Yes, unless you are changing the 'nature' of a contained object. i.e
- (void)setVal:(id)newVal {
[val autorelease];
val = [newVal copy];
}
3. If I got a new object from the system frameworks via any method but
'alloc', it will get implicitly autoreleased, so I have to retain it
if I
want it to persist beyond the next RunLoop cycle.
If the object is created using a convience method, i.e [NSArray
arrayWithObjects:objOne, objTwo, nil] the object (if the method is written
correctly is autoreleased before it is returned to you. So you should
not release it.
4. It's OK to release objects that were allocated by another thread
(assuming that the other thread properly retained what it still needs.)
I find it generally safer not to, but if you do. Call autorelase
not release. This delays the release call until the end of the run loop, allowing
the object to still be used in other areas of the app.
5. Similarly, auto-release pools in multiple threads won't auto-collide
even
if they contain some of the same objects.
I believe that there should generally only be one autorelease pool,
special cases excluded.
6. Objects that get added to a framework collection object (such as an
NSArray) will be retained by the collection, so they should be released
by
the application after adding them if there are no references elsewhere.
Yes, NSArray, NSSet .... retain each object they contain. and
likewise release each object when they are removed.
7. If I hand an object to a system framework method, the docs for it
ought
to tell me explicitly if the framework is ever then going to release or
retain that object (which it usually doesn't.)
They generally don't modify your object (including its reference
count) if they are written correctly.
BTW, some things are still mysterious, like NSTimers. Who really owns
them,
anyway? Are they autoreleased when they are invalidated or expire?
Should I
release them immediately if all I want is to get the firing message
later?
NSTimers are created with a Class Method (that little + denotes a
class method) so when the object is created I would assume it is
autoreleased before it is returned to you. But the NSTimer itself is
registered to the default run loop, and stays there until you invalidate
it (which is the only way to remove it from the run loop, repeating
timer or not).
8. A "retain chain" must not loop - i.e. Object ownership should be
uni-directional.
I don't know what you mean by this.
9. One should not attempt to re-use objects by re-initing them.
no.
10. It is bad practice to do: id bar = [Foo alloc]; [bar init]; because
init
might hand back a different object than the original alloc did.
This is programmatically similar to nesting the two i.e id bar =
[[Foo alloc] init]. So i think it makes no difference.
Did I mess up here, or miss something?
Thanks!
---Chris
Roarke Lynch
-------------------------------
email@hidden
_______________________________________________
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.