Why use TT_RELEASE_SAFELY in three20 for iPhone?

Question

#define TT_RELEASE_SAFELY(__POINTER) { [__POINTER release]; __POINTER = nil; }

Why is does three20 consider it safe to assign an ivar to nil after releasing it? Is it unsafe to leave out the ivar = nil step?

This is all I found: http://github.com/facebook/three20/commit/1b946f475fb28d60e0aafc9ef394050c642c3a5b#commitcomment-115517

I don't think I'm using KVO/KVC, but I'm not really sure. I'm reading up on it now.

Thanks!

Matt

Answer 1

In particular for the case of releasing ivars in dealloc there is a fair amount of debate in the community about whether it is better to set them to nil after releasing or not.

The pro-nil camp feel that in general it makes the app less likely to crash in the unfortunate case where an object is accessed after being deallocated, or even during in the case of multi-threaded applications.

The anti-nil camp doesn't feel like the above argument is particularly useful because they feel the app SHOULD crash in such a case to make it that much more obvious that your application has a defect (it is accessing a deallocated object).

That's not necessarily the most comprehensive summary of the positions, but it gives you an idea of the "controversy" involved.

The KVO/KVC issue is somewhat separate as that is an argument not about whether to set the ivar to nil, but whether it's safe to use the setter of a property to do so because of possible side-effect issues (like KVO/KVC).

Answer 2

When inside -dealloc, this question splits the Objective-C gurus. read this recent blog entry for example.

When inside an implementation of other methods, my personal opinion is that you shouldn't keep the variable in scope after the release in the first place. This code

   SomeClass* someObject= ...
   ... use someObject ...
   [someObject release]; 
   ... more code ...

might accidentally access someObject later in code, thus leading to a crash. So you might say

   SomeClass* someObject= ...
   ... use someObject ...
   [someObject release];
   someObject=nil; 
   ... more code ...

would be better, because messaging to nil is harmless. However, in this case you can remove the danger altogether:

   {
      SomeClass* someObject= ...
      ... use someObject ...
     [someObject release]; 
   }
   ... more code ...

Here I'm using a {...} block to limit a scope of a variable. Then the use of someObject later is simply a compile-time error.