Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Steve Christensen <email@hidden>
- Date: Tue, 19 May 2015 09:54:52 -0700
On May 19, 2015, at 8:52 AM, Britt Durbrow <email@hidden> wrote:
>
>> On May 19, 2015, at 7:20 AM, Steve Christensen <email@hidden> wrote:
>>
>> I just finished catching up on the discussion and keep coming back to the fragile nature of relying on retainCount. For now you do, indeed, have the option to vaporize your toes; later you may not have access to a ray gun if Apple decides that it's in the best interests of all concerned that they retain their toes, not their objects.
>
> Restating a previous concern of mine:
>
>> However, it’s not actually something that’s likely to get deprecated; and by paying very careful attention to the rules, it should be OK to use in this very narrow circumstance?
>>
>> If this is wrong - please (hopefully someone from Apple) correct me!
>
> Yes, I am a bit concerned that it could become deprecated. I suppose that I could just override retain and release in that case; and track the retain count myself; although I seriously doubt that that functionality will be deprecated/removed as there’s too much oddball stuff that depends on it… but uggghhhh… that’s nasty. To borrow a phrase from a lolcat, “DO! NOT! WANT!” :-)
I'm not saying that retain/release management would go away entirely, just that could be made private to the compiler's management of ARC, for example, if Apple decides that ARC, Son of Arc, etc., is the only way to manage object lifespan.
> I don't know what your app architecture looks like, but was wondering if you could build in a supportable method of managing what's in the cache without having to do other than a few localized changes.
>>
>> One thought I had was to base all your cacheable objects on a class whose sole function is to notify the cache when the last reference goes away, i.e., when dealloc is called. If the cache kept track of all cached objects using a NSMapTable with weak references then the cache itself wouldn't affect the retain count, so you'd never have to be looking at that. Reads from and writes to the NSMapTable would need to be protected for consistency.
>>
>> Does this sound like it could work?
>
> Um… that’s just a weak link? And the only way for an instance to know that it’s got a reference to it outstanding is to override retain and release?
Yes, the cache would be keeping a weak link to each of the in-memory objects it manages via a NSMapTable so that it doesn't affect the retain count of the current actual users of individual objects. By overriding dealloc in a cacheable object base class then you know for a fact that there are no more references to the object since that's the only time that dealloc will be called. Once that dealloc method notifies the cache to remove the object from its NSMapTable then the cache should be in a consistent state.
The other benefit of creating this base class (assuming that you don't already have one) is that you don't have to be modifying code all over the place, just creating the common dealloc method and modifying the @interface statements in some headers so that the objects inherit.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden