Re: Calling -retain inside -dealloc
Re: Calling -retain inside -dealloc
- Subject: Re: Calling -retain inside -dealloc
- From: j o a r <email@hidden>
- Date: Mon, 27 Jun 2005 08:03:55 +0200
On 27 jun 2005, at 03.51, Andrew Garber wrote:
Why I'm doing this is quite complex, so I won't get into
the details.
Whenever I hear this I get suspicions - if you can't explain your
design, it's almost certainly not a good one.
So, the retain count is zero when entering the -dealloc method, then
it gets incremented to 1, then it gets decremented back to zero.
Note that if you do proper memory management, the retain count will
never be zero in this implementation, and dealloc will hence never be
called.
Is there any risk that when the retain count drops to zero the second
time, -dealloc will be called again, causing an endless loop?
No, se above.
On 27 jun 2005, at 07.46, Andrew Garber wrote:
I have several callback functions which are triggered quite frequently
(like every 2ms or so).
That is frequently!
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.
NSNotification is not really a high-performance solution. It's much,
much, much, improved in Tiger though.
You say that you allocate / deallocate instances of this class
"rarely", so it probably makes sense to do all the sorting needed at
allocation time - to be able to have pre-sorted lists of objects to
iterate over when you get your callbacks.
That said, I don't understand why your need to have efficient
callback functions would make it necessary to override regular Cocoa
memory management?
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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