Welcome to the MacNN Forums.

Brass · Jun 30, 2002, 10:57 PM

Which is correct in a custom object's dealloc method (usually the last line)?

[super release];

OR

[super dealloc];

To me, [super release]; makes more logical sense, but it crashes (by apparently running the custom dealloc method again). And I'm sure that's what the text book said to use.

But I don't have the textbook here anymore to check. Which is correct and why?

[ 06-30-2002, 11:57 PM: Message edited by: Brass ]

Ghoser777 · Jun 30, 2002, 11:21 PM

Think about what you're doing for a second. Your calling super's implementation of release. Now, unless you've overridden that (and I wouldn't suggest doing that), [super release] will do the same thang as [self release]. So, you're essentially sending an extra release message to your object, and so it dies.

[supre dealloc], on the other hand, executes super's implementation of dealloc, which is a good thing to do, as your overriding dealloc. You want to be able to to do the standard deallocing and any custom deallocing you want to do. So, if you have two objects in your class, say Larry and Bob, which you want to make sure get released, you would do this:

<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">- (void)dealloc
{
[Larry release];
[Bob release];
[super dealloc];
}</pre><hr /></blockquote>This way, self isn't disposed of until after Larry and Bob are sent release messages, which is another good thing.

Hope that helps,
F-bacher

Brass · Jun 30, 2002, 11:33 PM

<blockquote>quote:<hr />Originally posted by Ghoser777:
Think about what you're doing for a second. Your calling super's implementation of release. Now, unless you've overridden that (and I wouldn't suggest doing that), [super release] will do the same thang as [self release]. So, you're essentially sending an extra release message to your object, and so it dies.

[supre dealloc], on the other hand, executes super's implementation of dealloc, which is a good thing to do, as your overriding dealloc. You want to be able to to do the standard deallocing and any custom deallocing you want to do. So, if you have two objects in your class, say Larry and Bob, which you want to make sure get released, you would do this:

<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">- (void)dealloc
{
[Larry release];
[Bob release];
[super dealloc];
}</pre><hr /></blockquote>This way, self isn't disposed of until after Larry and Bob are sent release messages, which is another good thing.

Hope that helps,
F-bacher<hr /></blockquote>Thanks, that fits with what I thought was happening. It's taking a while for all this to sink in, but I think I'm getting it now...

When a [super method] is invoked, it is over-ridden by the subclass, unless it is that over-riding subclass method that is invoking it. Is that correct? Otherwise, calling [super dealloc] would invoke [self dealloc] the same as [super release] does.

smeger · Jul 1, 2002, 01:33 AM

When you call a super's method, you're calling the method as if your subclass didn't exist. Super has no knowledge of your subclass.

So, for the release vs. dealloc question, you need to call dealloc. Generally, a class instantiates variables that need to be released when the class is cleaned up. If you call [super release], the memory used by your object is released, but any instance variables that super allocated never get released.

Whereas, if you call [super dealloc], super's dealloc method is executed, in which super deallocates anything it allocated. Super then calls its super, etc., until finally NSObject's version is reached.

It's almost always a good idea not to break the inheritance chain. This is also why you call super's init method from your subclass.

So, when you call super's method, that's what gets executed. When you call self's method, your version gets called.

Capiche?

Thilo Ettelt · Jul 6, 2002, 05:39 PM

<blockquote>quote:<hr />Originally posted by Brass:
Which is correct in a custom object's dealloc method (usually the last line)?

[super release];

OR

[super dealloc];

To me, [super release]; makes more logical sense, but it crashes (by apparently running the custom dealloc method again). And I'm sure that's what the text book said to use.

But I don't have the textbook here anymore to check. Which is correct and why?<hr /></blockquote>With [super dealloc] your deallocating a class. So that should be the last thing your doing in a fuction! Anything else has to stand before this thing.

Cheers, Thilo

Chuckit · Jul 6, 2002, 08:02 PM

<blockquote>quote:<hr />Originally posted by Thilo Ettelt:
With [super dealloc] your deallocating a class.<hr /></blockquote>What? Why would [super dealloc] deallocate a class? The super keyword doesn't actually refer to the superclass class object--it just tells your object to use the superclass's implementation of a method.

And I don't think there even is a +dealloc method....

Thilo Ettelt · Jul 7, 2002, 06:13 AM

<blockquote>quote:<hr />Originally posted by Chuckit:
 <blockquote>quote:<hr />Originally posted by Thilo Ettelt:
With [super dealloc] your deallocating a class.<hr /></blockquote>What? Why would [super dealloc] deallocate a class? The super keyword doesn't actually refer to the superclass class object--it just tells your object to use the superclass's implementation of a method.

And I don't think there even is a +dealloc method....<hr /></blockquote>uhm, don't you release objects and dealloc classes?

Cheers, Thilo

Chuckit · Jul 7, 2002, 07:44 AM

<blockquote>quote:<hr />Originally posted by Thilo Ettelt:
uhm, don't you release objects and dealloc classes?<hr /></blockquote>I don't think so. From Apple's docs:
<blockquote>quote:<hr />release

- (oneway void)release

Decrements the receivers's reference count, and sends it a dealloc message when its reference count reaches 0.<hr /></blockquote>Release just decrements the retain count. It's dealloc that actually destroys the object.

Incidentally, it's also mentioned in Apple's docs that you should call [super dealloc] at the end of your custom dealloc method. Just to lend some of that official Apple oomph to Ghoser and smeger's comments.

(Oh, and no, I did not make that up. They actually wrote "receivers's.")