RE: Calling -retain inside -dealloc
RE: Calling -retain inside -dealloc
- Subject: RE: Calling -retain inside -dealloc
- From: Jeff Laing <email@hidden>
- Date: Mon, 27 Jun 2005 15:57:04 +1000
> mmalc,
>
> I have several callback functions which are triggered quite frequently
> (like every 2ms or so). Inside each of these a callbacks, I need to
> invoke methods for each instance of my class that matches a certain
> criteria. In a previous paradigm, I used NSNotifications. I'm now
> trying to see if I can speed things up a little.
>
> Also, the instances of my class will rarely be deallocated.
I don't know that this explained the problem well (which is a bit arrogant,
since I'm just an interested bystander :-) so I'll clarify my understanding
of what Andrew needs.
Andrew has a class T.
For architectural reasons, he also has an array somewhere which references
every instance of T.
Lets assume thats not optional for now.
Its not a retaining array, or else his retain count will never go down to
one without it also having been removed from the array.
In [T init], the instance of class T will add itself to the array.
He wants the retain/release mechanism to automatically remove the reference
whenever T is finally dealloc'd
This is a pattern that I have needed in the past as well, so I'd be
interested in alternate solutions. Personally, I find the 'unref it whenever
[T release] is called' a little nasty tasting, but it does seem to be the
lightest-weight solution.
I'm not certain that there is really a need for T to be left in the array
until the final release is called - I'm sure that at some point, the
application realises that it no longer wants to talk to the T and it could
explicitly remove it then, rather than potentially have the T instance hang
around a log longer (perhaps in an autorelease pool), and thus get his
callbacks firing in "almost dead" instances. But thats beside the point,
from the discussion of the abstract pattern which I'd like to see continued.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden