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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
