Question

I have a situation in my code, where I cannot clean up my classes objects without first calling [super dealloc]. It is something like this:

// Baseclass.m
@implmentation Baseclass

...

-(void) dealloc
{
    [self _removeAllData];
    [aVariableThatBelongsToMe release];
    [anotherVariableThatBelongsToMe release];
    [super dealloc];
}

...

@end

This works great. My problem is, when I went to subclass this huge and nasty class (over 2000 lines of gross code), I ran into a problem: when I released my objects before calling [super dealloc] I had zombies running through the code that were activated when I called the [self _removeAllData] method.

// Subclass.m
@implementation Subclass

...

-(void) dealloc
{
    [super dealloc];

    [someObjectUsedInTheRemoveAllDataMethod release];
}     

...

@end

This works great, and It didn’t require me to refactor any code. My question Is this: Is it safe for me to do this, or should I refactor my code? Or maybe autorelease the objects?

I am programming for iPhone if that matters any.

Answer 1

Okay, I was talking rubbish. [super dealloc] does need to be called last.

Of course, this doesn’t answer your question.

Without looking at your code it’s hard to see, but the trouble seems to come from the _removeAllData method

Firstly, you shouldn’t be prefixing methods with an underscore as that prefix is reserved by Apple (Reference) for private methods.

Secondly, it is obviously used for tidying up the object and might be releasing objects that you are then manually releasing later on. It could even be releasing objects defined in one of the super classes that are then being over released in [super dealloc].

So, after a bit of thought (more than it should have taken, really) the problem isn’t in where your super’s dealloc is called; but in what is being cleaned up and when.

Sorry about my earlier mistake, and thanks to the commenters who persuaded me of my error rather than letting me persist in my error.

Original answer

Yes. As long as you don’t try to use any of the superclass’s variables.