Re: NSString Retain Count of 2147483647
Re: NSString Retain Count of 2147483647
- Subject: Re: NSString Retain Count of 2147483647
- From: Jean-Daniel Dupas <email@hidden>
- Date: Wed, 24 Jun 2009 18:03:04 +0200
Le 24 juin 09 à 17:45, Martin Redington a écrit :
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
And it should not be an issue as you should not use it after release
(the Static Analyzer will warn you if you do something like that).
_______________________________________________
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