objective-c over-releasing in dealloc

Is mystring over-released?

-(void)dealloc {
    [mystring release];
    [mystring release];
    [super dealloc];
}

I assume this will not based on [nil release] does nothing:

-(void)dealloc {
    [mystring release];
    mystring = nil;
    [mystring release];
    [super dealloc];
}

-EDIT- Let's say I allocate mystring in init and release it in doSomething:

-(id)init {
    if (self = [super init]) {
        mystring = [[NSString string] retain];
    }
    return self;
}
-(void)doSomething {
    [mystring release]; // for some good reason
    // ...etc
}

Now to avoid over-releasing in dealloc based on my example above do I have to explicitly do this in the doSomething method?

-(void)doSomething {
    [mystring release];
    mystring = nil; // <- is this mandatory to avoid over-releasing in dealloc?
}

The big question is do I have to explicitly set it to nil when I release it somewhere else in the class to avoid over-releasing in dealloc?

So could I do as many releases as I want in dealloc based if I explicitly set to nil in doSomething?

-(void)dealloc {
    [mystring开发者_高级运维 release];
    [mystring release]; // <- does nothing because mystring explicitly nil?
}

---

For your first example, the answer is probably!

In general, each object that holds a reference to another object should retain it until they're done, then call release once, however in some highly exotic (and generally poorly written) cases this may not hold. If you retain the object x times, you need to release it x times, and other cases of poor memory management. But best practice, yes, one retain, one release, don't release more than you retain!

There are two risks with over-releasing like this:

The first is if the first release call makes the refcount of mystring equal to 0, it will be dealloc'd, and then you're sending a message to a piece of memory that is no longer a valid object. Objective-C doesn't really like this, and may react in a variety of ways, including CRASHING. Sending messages to nil, kosher, messages to things dealloc'd, not so much.

The second is if the refcount isn't zero, you just released someone else's reference, so at some point in the future, an object that has a reference to mystring may think that reference is valid and it won't be because it was dealloc'd when the refcount hit zero on a subsequent release call. This will be harder to detect than the previous error, where a debugger will at least show you the real area the problem originates from in the stack frame trace.

Your second example is correct - sending a message to nil does nothing. If you fear you'll do things like this, be sure to set your variables to nil after releasing.

EDIT: Yes. That's what you should do if you intend to release in more than one place like that, however depending on the application, you might consider using an auto-release pool.

---

It all depends on how many time you retained mystring. If you have two members that may refer to the same object and both retain the object, they should both release the object.

So your first example would be correct if you use mystring = [[somestring retain] retain];

---

The second one will be better. Because when you release, you release the memory the mystring point to not the memory of the mystring. So, the mystring is not null and if somebody accidentally use it, your app will crash. It also depends on how many times your mystring is retained