Re: monitoring retainCount
Re: monitoring retainCount
- Subject: Re: monitoring retainCount
- From: Drew Thaler <email@hidden>
- Date: Wed, 26 May 2004 22:00:30 -0400
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.