Note that there are some explanatory texts on larger screens.

plurals
  1. POCalling -retainCount Considered Harmful
    text
    copied!<p><strong>Or, Why I Didn't Use <code>retainCount</code> On My Summer Vacation</strong></p> <p>This post is intended to solicit detailed write-ups about the whys and wherefores of that infamous method, <code>retainCount</code>, in order to consolidate the relevant information floating around SO.*</p> <ol> <li><p>The basics: What are the official reasons to not use <code>retainCount</code>? Is there ever any situation <em>at all</em> when it might be useful? What should be done instead?** Feel free to editorialize. </p></li> <li><p>Historical/explanatory: Why does Apple provide this method in the <a href="http://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html#//apple_ref/occ/intf/NSObject"><code>NSObject</code> protocol</a> if it's not intended to be used? Does Apple's code rely on <code>retainCount</code> for some purpose? If so, why isn't it hidden away somewhere?</p></li> <li><p>For deeper understanding: What are the reasons that an object may have a different retain count than would be assumed from user code? Can you give any examples*** of standard procedures that framework code might use which cause such a difference? Are there any known cases where the retain count is <em>always</em> different than what a new user might expect?</p></li> <li><p>Anything else you think is worth metioning about <code>retainCount</code>?</p></li> </ol> <hr> <p><sub>* Coders who are new to Objective-C and Cocoa often grapple with, or at least misunderstand, the reference-counting scheme. Tutorial explanations may mention retain counts, which (according to these explanations) go up by one when you call <code>retain</code>, <code>alloc</code>, <code>copy</code>, etc., and down by one when you call <code>release</code> (and at some point in the future when you call <code>autorelease</code>).</sub></p> <p><sub>A budding Cocoa hacker, Kris, could thus quite easily get the idea that checking an object's retain count would be useful in resolving some memory issues, and, lo and behold, there's a method available on every object called <code>retainCount</code>! Kris calls <code>retainCount</code> on a couple of objects, and this one is too high, and that one's too low, and what the heck is going on?! So Kris makes a post on SO, "What's wrong with my memory management?" and then a swarm of &lt;bold&gt;, &lt;large&gt; letters descend saying "Don't do that! You can't rely on the results.", which is well and good, but our intrepid coder may want a deeper explanation.</sub></p> <p><sub>I'm hoping that this will turn into an FAQ, a page of good informational essays/lectures from any of our experts who are inclined to write one, that new Cocoa-heads can be pointed to when they wonder about <code>retainCount</code>. </sub></p> <p><sub>** I don't want to make this too broad, but specific tips from experience or the docs on verifying/debugging retain and release pairings may be appropriate here.</sub></p> <p><sub> ***In dummy code; obviously the general public don't have access to Apple's actual code.</sub></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