GC and CF collections

Christiaan Hofman cmhofman at gmail.com
Sun Jul 6 12:33:45 PDT 2008


On 6 Jul 2008, at 4:23 PM, Jim Correia wrote:

> On Jul 6, 2008, at 9:51 AM, Christiaan Hofman wrote:
>
>> One situation is if I just want to retain the objects, in which  
>> case I usually make use of the standard kCFType...Callbacks.  
>> However those use CFRetain/CFRelease AFAIK. So it seems to me that  
>> they would basically make the objects I store uncollectable. Is  
>> that correct? If so, should I use some custom callbacks using - 
>> retain/-release? Or are the CFType...Callbacks now able to enable  
>> proper garbage collection?
>
> As long as the collection has a reference to the object it is not  
> collectable.

How can this be true, considering that NS collections are implemented  
as CF collections?

> This is the usual use case (where you'd use the standard callbacks)  
> and works correctly. If you have more complex needs, you need a  
> different solution.

So does this imply that NS collections definitely don't use  
kCFType...Callbacks behind the scene? And can I avoid it by using  
custom callbacks? Or does this apply to *any* callbacks?

It doesn't really make sense to me.

>
>> Another use is a static CFMutableDictionaryRef to track simulated  
>> ivars. This means that I register pairs of an object and a  
>> simulated ivar, using the object as key and the simulated ivar as  
>> value. The keyCallbacks for the dictionary are trivial, because  
>> otherwise the object used as key will never be deallocated (and  
>> this is the main reason I'm using CFMutableDictionary). This works  
>> great with managed memory.
>>
>> However I wonder now if this can work with GC. Is the garbage  
>> collector able to clean up the object, even if it is referenced as  
>> a key by the CFMytableDictionary?
>
> You should consider migrating your special needs code which uses CF  
> collections with custom callbacks to NSMapTable and NSPointerArray  
> in your GC-savvy code. It has options for strong or weak objects or  
> keys, and does the correct thing with respect to GC and write  
> barriers.
>
> Jim

But that's Leopard only. What if I want to allow the same code to  
build for Tiger as well (using different build settings)?

Christiaan




More information about the MacOSX-dev mailing list