Re: Simple dealloc question
Re: Simple dealloc question
- Subject: Re: Simple dealloc question
- From: Ricky Sharp <email@hidden>
- Date: Mon, 15 Oct 2007 15:50:13 -0500
On Oct 15, 2007, at 4:50 AM, Milo Bird wrote:
That's correct but only for this object. Application can be trying
to send messages to this object forever. And setting nil will help
to track it down.
I'm sorry, I don't follow this argument... What do you mean,
"application can be trying to send messages to this object forever"?
In my opinion, setting instance variables to nil in dealloc is a
cautious step too far. Any messages sent to the object in error
after dealloc could end up anywhere. What does it matter if the
instance variables point to released objects, when the receiver is
itself a released object?
I have one more question. In the same code there is
// Standard accessors
- (Track *)track
{
return [[track retain] autorelease];
}
Why not just
// Standard accessors
- (Track *)track
{
return track;
}
Consider the following snippet:
Track *track = [someObject track];
[someObject setTrack:[[[Track alloc] init] autorelease]]; //
Assuming there is a setter!
NSLog(@"%@", track); // track has been released, unless the
accessor retained or copied the return value...
If your object is mutable and the accessor simply returns the
instance variable, it may get released inadvertently before the
caller is finished with it. Retaining and then autoreleasing avoids
this problem.
Note that neither convention is necessarily wrong. Apple tends to
use the latter form in their own classes, despite the fact that
it's less safe.
FWIW, I use both patterns. If an ivar is private, I'll always use
the latter.
However, for all non-private ivars, I go with the former pattern.
While technically slower, the speed hit I personally take is
effectively zero (i.e. not used in nested loops or other process-
intensive work). And the amount of time it would take to
individually analyze each ivar for what pattern would be best would
be quite high. Thus, I decided to take the easy route and just play
it safe all the time with such ivars.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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