Re: monitoring retainCount
Re: monitoring retainCount
- Subject: Re: monitoring retainCount
- From: Stefan Fisk <email@hidden>
- Date: Thu, 27 May 2004 06:04:53 +0200
well, my motivation is suspect =)
the idea of caching the objects just struck me as sane, if it was
doable, which it doesn't seem to be without hacks like poseAs:[NSObject
class], and i'm very skeptical to stuff like that, to say the least..
2004-05-27 kl. 04.00 skrev Drew Thaler:
On May 26, 2004, at 7:12 PM, Stefan Fisk wrote:
i think you all are missing the point, i want to monitor the retain
count in code, so that i can know when the objects i've created get
destroyed, without polling each pass through the runloop etc.. what
you're suggesting are debugging aids, i want to be notified atleast
every time retainCount changes, preferably only when it reaches 0,
and it should work while deployed on "vanilla" installs of os x..
First of all, your motivations seem suspect - the reason there's no
simple non-debug way to do what you seem to be looking for is because
it's not a good idea in practice. :-)
Classes are supposed to notify about actual events, things that change
whatever it is they are representing, rather than retain/release
(which is really a non-event).
Ask yourself if there's a better way to do whatever it is you want.
What's the larger objective you're trying to accomplish? Preventing an
object from being destroyed? Something else? Try asking a question
about that instead.
Still, I'm a believer in giving you enough rope to hang yourself ...
if the objects you're concerned with are classes you've defined and
implemented, you can implement -retain, -release, and -dealloc in your
objects to send messages (ie, post an NSNotification or something) as
long as you remember to pass the original message up to the
superclass. Just be sure you don't do anything that will modify the
object's retain count from there, like passing it as the
NSNotification's object param, or you will get caught in a loop!
If you're concerned with objects that are NOT instances of classes
that you define, you REALLY should reconsider why you think you need
to do this. :-) Except in very rare cases, it's probably a really bad
idea and there's probably a better way. (A rare case might be: you're
using a third-party framework (without source) which does not provide
a solution for a problem you're having, you cannot solve your problem
with a subclass or a category, and you're on an absolute deadline and
you have no other choice.)
If you are sure you have one of those rare cases where you must
monitor retains/releases at runtime for some non-debugging reason, you
might have to consider something like APE Lite to patch/intercept the
retain/release methods you care about while still being able to call
through. But that would be an extreme solution. There's probably a
simpler way.
drew
--
Drew Thaler
Recording Artist
Email/AIM: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.