iPhone - dealloc - Release vs. nil

Question

Wondering if someone with experience could possibly explain this a bit more. I have seen examples of...

  [view release];

  view = nil;  

Answer 1

@bbullis22 you have seen the restain count drop from 3 to 0 because you set the reference to nil. then you asked for the retaincount of 'nil' which is zero. however, the object that used to be referenced has the same retain count - 1 (due to setting the reference to nil). using release, the reference still references the same object, so that's why you see the retain count drop from 3 to 2 in this situation.

Answer 2

I think using both is kind of safety net. With only release in place you could run in problem if you screwed reference counting management. You would release an object, giving its memory back to system but pointer would be still valid.

With nil you are guaranteed that program will not crash since sending message to nil does nothing.

Answer 3

If you are not using properties (where self.property = nil will also release an object) then you should ALWAYS follow a release by code that sets the reference to nil, as you outlined:

[view release]; view = nil;

The reason is that it avoids he possibility that a reference can be used that is invalid. It's rare and hard to have happen, but it can occur.

This is even more important in viewDidUnload, if you are freeing IBOutlets - that's a more realistic scenario where a reference might go bad because of memory warnings unloading a view, and then some other code in the view trying to make use of a reference before the view is reloaded.

Basically it's just good practice and it will save you a crash at some point if you make it a habit to do this.

Answer 4

What you have seen is probably these:

1) [foo release];
2) self.bar = nil;
3) baz = nil;

1. Is releasing the object, accessing it through the instance variable foo. The instance variable will become a dangling pointer. This is the preferred method in dealloc.

2. Is assigning nil to a property bar on self, that will in practice release whatever the property is currently retaining. Do this if you have a custom setter for the property, that is supposed to cleanup more than just the instance variable backing the property.

3. Will overwrite the pointer baz referencing the object with nil, but not release the object. The result is a memory leak. Never do this.

Answer 5

As far as usage inside your code, in your dealloc you don't need the assignment to the property, releasing is all you need to do.

- (void)dealloc {
    [myProperty release]; // don't need to assign since you won't have the object soon anyway
    [super dealloc];
}