Re: dealloc and instance variables
Re: dealloc and instance variables
- Subject: Re: dealloc and instance variables
- From: Jörn Salewski <email@hidden>
- Date: Sun, 23 Nov 2003 08:52:50 +0100
am 23.11.2003 7:16 Uhr schrieb Graeme Mathieson unter email@hidden:
>
If my object retains some other object in an instance variable, do I
>
have to explicitly write a -(void)dealloc method to release it when my
>
object is released?
YES, definitely.
Whenever you say init, copy or retain you must say release.
>
Take, for example:
>
>
@interface MyFooBar
>
{
>
NSString *baz;
>
}
>
>
- (id)initWithString:(NSString *)aString;
>
@end
>
>
@implementation MyFooBar
>
>
- (id)initWithString:(NSString *)aString
>
{
// if sString is an immutable NSString
// a simple retain is sufficient. The string
// can not be altered anyway and it saves a call
// to malloc().
// don't forget to call the designated initializer
// of the superclass to allow that class to init
// ist own ivars. E .g.
if (self = [super init]) {
>
baz = [aString copy];
}
return self;
>
}
>
@end
>
>
Do I need to also implement:
>
>
- (void)dealloc
>
{
>
[baz release];
// after releasing your own instance variables
// you must also call supers implementation of dealloc
// so that the superclass can free ist own ivars
[super dealloc];
>
}
>
>
?
>
>
I started out by thinking that yes, obviously I'd have to release any
>
objects I allocate. That makes sense and my code did work OK in the
>
limited testing I've done. But then I read
>
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/
>
4objc_runtime_overview/chapter_4_section_2.html which says:
>
>
> Releasing Instance Variables
>
>
>
> The purpose of a dealloc message is to deallocate all the memory
>
> occupied by the receiver. NSObjects version of the method deallocates
>
> the receivers instance variables, but doesnt follow any variable
>
> that points to other memory.
>
I think you missunderstand this passage. 'Deallocate the memory' doesn't
only mean cases when you explicitly called malloc, but also when you
retained memory.
What the passage say is that dealloc is the place where you balance retain -
release messages to objects you (your class) is responsible for. NSObjects
implementation does ist own job for ist own ivars, but doesn't care about
instance variables of superclasses (if there were any) or subclasses.
>
So I interpret that to say "any of your instance variables which are
>
handled through the reference counting mechanism are automatically
>
dealt with, but if you malloc() bits and pieces you have to deal with
>
that yourself" and fix my code appropriately. Annoyingly, all my code
>
still works fine.
>
>
To confound matters, whilst reading 'Cocoa in a Nutshell' yesterday
>
afternoon, I read (from page 15 of my edition):
>
>
> Deallocating Objects
>
> [...]If the object has created or retained any other objects'
>
> reference by its instance variables, it must implement this method and
>
> perform the appropriate tasks to maintain integrity of the reference
>
> counting system.
>
>
It then goes on to show a dealloc method where the object sends a
>
release to its instance variables before passing the message onto its
>
superclass.
>
>
So, which one is correct?
>
>
While I'm here, another quick question: Is it valid to send a message
>
to a nil object?
Yes, it is. Any 'return value' the message would give will be nil also.
Putting this together with your previous question. You could have an ivar
id foo;
in your FooBar class and say foo = nil; in your init method. Since FooBar is
responsible for the variable foo, it must [foo release]; it in its
implementation of dealloc, allthough it might be actually nil.
This way, if a subclass of FooBar, say FooBarSub, decides to assign a value
to foo, for example foo = [[NSString alloc]init], the subclass is not
'personaly' responsable for releasing foo and does not release foo directly
in its implementation of dealloc, but eventually does so by calling the
implementation of the superclass FooBar with [super dealloc];
>
My code currently doesn't make such an assumption, so
>
in a few cases I'm explicitly checking that a particular variable
>
points to an object rather than nil before sending a message. However,
>
my code would look far tidier if I was able to just send the message
>
anyway, so long as I was careful to reset instance variables to either
>
a valid object or nil.
_______________________________________________
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.