On Wed, Jun 24, 2009 at 4:05 PM, Clark Cox<email@hidden> wrote:
On Wed, Jun 24, 2009 at 7:58 AM, Gwynne Raskind<email@hidden
> wrote:
On Jun 24, 2009, at 10:26 AM, Thomas Wetmore wrote:
What you're talking about is an internal implementation
detail. You can't expect to rely on it for more than five minutes
at a time.
If monitoring the retain count of an object is the answer to your
problems,
then you're going about things completely wrong. Autorelease pools
and
singleton objects, to name two examples, make the use of retain
counts in
debugging a complete fallacy.
I can't second this advice enough. Anytime you're looking at the
retainCount directly, you're probably overthinking your issue.
Is that really always true?
I recently did a pass over one of my apps to correct some issues that
static analysis had thrown up, and also did some cleanup of memory
usage/issues - mostly over-retains as it turns out.
I found that inspecting retainCount with caveman debugging, and
over-riding retain/release/dealloc very helpful in some specific
contexts, for example to catch bugs like
id someObject = [[MyObject alloc] init];
[someArray addObject:someObject];
[someObject release];
// Oops. someArray was nil, and now someObject is gone
