Re: Releasing by reference
Re: Releasing by reference
- Subject: Re: Releasing by reference
- From: Uli Kusterer <email@hidden>
- Date: Thu, 2 Aug 2007 10:23:52 +0200
On 01.08.2007, at 16:02, Scott Morrison wrote:
-(void) dealloc{
if (mov) {
[mov release]; // I have
}
}
Oh, two more things:
1) the if(mov) check is unneeded, if mov is NIL, [mov release] will
be a message to NIL, which has no effect.
2) When you release an object, it's a good idea (particularly for
static variables that may be used by other objects) to set the
variable containing the pointer to it to NIL. That way, when someone
tries to access that object through this pointer variable, they can
see from mov being NIL that it's been released.
So a better version of this would be:
-(void) dealloc
{
[mov release];
mov = nil;
[super dealloc]; // Let superclass release its stuff, and the object
itself, too!
}
But as others have said: Only variables declared in the @interface of
a class between the "{" and "}" are per-instance variables. Variables
declared anywhere else have their regular C scope. So, "mov" here is
a bad choice for a static variable. First, because its pointed-to
object gets released in dealloc, so it's obviously used as a per-
instance variable. Second, because static variables and other globals
should generally have a name prefix to make it obvious what they are.
I personally prefer sMovie for statics and gUKClassAMovie for globals
visible in other files, though the "official" Cocoa convention seems
to be using class-like names, i.e. UKClassAMovie, instead.
If you want this to be a shared variable, but still lazily load
whatever goes in there, you should probably just do an "intentional
leak". I.e. whenever someone changes it, you still release the old
object and retain the new one, but when your last object goes away,
you just leave it in this variable. When a new object is allocated
afterwards, it can still access this object through the global or
static, and when your application quits, your memory space gets
reclaimed anyway, so it gets cleaned up anyway.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
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