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
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
then you're going about things completely wrong. Autorelease pools
singleton objects, to name two examples, make the use of retain
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];
// 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