Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The dealloc method is called on an object when it's retain count has reached zero. Retain counts are increased by one for each <code>retain</code> call, and reduced once for each <code>release</code> call. The <code>autorelease</code> schedules a future <code>release</code> call when the current NSAutoreleasePool is drained, typically at the end of an event cycle, but you can set up your own NSAutoreleasePools on memory intensive operations. (See the NSAutoreleasePool docs for details.)</p> <p>What should you put into dealloc? You should put a release for each member object the object of that class retains.</p> <p>A couple things make this easier. The nil object will quietly ignore any messages sent to it, so [foo release] when foo = nil is not a bug. However, releasing an object twice can cause serious issues. My (hardly unique) solution to this is to explicitly set whatever I just released to nil, whenever I release it. In fact, I put the nil assignment on the same line as the release so I can grep for "release" and find places I missed. Example:</p> <pre><code>@interface MyClass { Foo *foo; Bar *bar; NSInteger baz; } -(void)dealloc; @end @implementation MyClass -(void)dealloc { [foo release]; foo = nil; [bar release]; bar = nil; [super dealloc]; } @end </code></pre> <p>I'll assign nil to a variable <em>even when that variable is about to go out of scope</em> or <em>the object is about to go away.</em> Why? If another object of the same class is allocated in the same memory space after I've released this one, it <em>guarantees</em> there will be no dangling pointers the new object might accidentally use and make debugging a nightmare. (See also NSZombieEnabled for debugging help.)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload