Cocoa mail archive
Re: Intercepting retain/release of object
FROM : Jack Repenning
DATE : Mon Mar 24 05:31:12 2008
On Mar 21, 2008, at 2:36 PM, Sherm Pendley wrote:
> In short, the fact that you need a means to track down your -retain
> and
> -release calls is indicative of a deeper problem. Examining the
> retain count
> will not only fail to solve that problem, but will also obfuscate
> the issue
> even further. You'd be far better off asking yourself why your -
> retains and
> -releases are so scattered that they're difficult to find and verify
> in the
> first place - that's the *real* problem, not whatever arbitrary
> value you
> happen to get back from -retainCount.
There are really two bits of advice, here, and they're separable.
The first is: you'll never make any sense out of retainCount. Might
as well just take that one to the bank. Forget retainCount. There's
way too much stuff going on that you can't see in the code, you'll
never make sense of it all. That's the easy part.
The second is: it's best form to handle your retain/release stuff in
the simplest, most on-sight verifiable way you possibly can. If you
find yourself wondering where an extra or missing retain or release
is, then your best conclusion is that your retain/release code is too
confusing. Doing it in the accessors is the simplest, most at-a-
glance policy, and it covers most use. In fact, Obj-C 2.0 provides
you with a handy short hand to do it exactly this way,
@property(retain). Breaking in reatain and release (and maybe
autorelease) can tell you things that make sense (unlike retainCount),
but if you have to do that, your code's too complicated -- you'll have
to do it again and again, every time you make changes. Save yourself
the trouble. Simplify.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
DATE : Mon Mar 24 05:31:12 2008
On Mar 21, 2008, at 2:36 PM, Sherm Pendley wrote:
> In short, the fact that you need a means to track down your -retain
> and
> -release calls is indicative of a deeper problem. Examining the
> retain count
> will not only fail to solve that problem, but will also obfuscate
> the issue
> even further. You'd be far better off asking yourself why your -
> retains and
> -releases are so scattered that they're difficult to find and verify
> in the
> first place - that's the *real* problem, not whatever arbitrary
> value you
> happen to get back from -retainCount.
There are really two bits of advice, here, and they're separable.
The first is: you'll never make any sense out of retainCount. Might
as well just take that one to the bank. Forget retainCount. There's
way too much stuff going on that you can't see in the code, you'll
never make sense of it all. That's the easy part.
The second is: it's best form to handle your retain/release stuff in
the simplest, most on-sight verifiable way you possibly can. If you
find yourself wondering where an extra or missing retain or release
is, then your best conclusion is that your retain/release code is too
confusing. Doing it in the accessors is the simplest, most at-a-
glance policy, and it covers most use. In fact, Obj-C 2.0 provides
you with a handy short hand to do it exactly this way,
@property(retain). Breaking in reatain and release (and maybe
autorelease) can tell you things that make sense (unlike retainCount),
but if you have to do that, your code's too complicated -- you'll have
to do it again and again, every time you make changes. Save yourself
the trouble. Simplify.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
