Re: Garbage Collection, Core Foundation, and the -finalize problem
Re: Garbage Collection, Core Foundation, and the -finalize problem
- Subject: Re: Garbage Collection, Core Foundation, and the -finalize problem
- From: "Sean McBride" <email@hidden>
- Date: Tue, 17 Mar 2009 17:27:03 -0400
- Organization: Rogue Research Inc.
On 3/17/09 5:35 AM, Bill Cheeseman said:
>>> I am looking for a strategy to avoid implementing a -finalize
>>> method in a garbage-collected Objective-C class that declares a
>>> CFTypeRef-style Core Foundation instance variable. I believe this
>>> is a fairly common problem, because any Cocoa wrapper class for a
>>> Core Foundation API would have to do it, but I haven't seen a
>>> usable solution. Apple's GC documentation stops just short of
>>> suggesting an answer.
>>
>>
>> I believe you're supposed to declare your CFTypeRef ivar as __strong
>> and call CFMakeCollectable so that the garbage collector will be
>> responsible for releasing it. You can still use CFRelease in -
>> dealloc for when you aren't running under garbage collection.
>
>After thinking on this overnight, I have concluded that in a mixed-
>mode framework the best practice is indeed to call CFMakeCollectable
>as soon as the CFTypeRef ivar is created so that garbage-collected
>clients can ignore memory management issues.
I agree. Using NSMakeCollectable() combined with autorelease makes your
code safe in both RR and GC. For example:
CFURLRef theURL = CFURLCreateFromFSRef(
kCFAllocatorDefault, fsRef );
[NSMakeCollectable(theURL) autorelease];
BTW, NSMakeCollectable() is nicer since it avoids a cast.
>As a corollary, when the problem domain served by the framework is
>such that there is no convenient way to know when to call an -
>invalidate method, simply put all the cleanup code in -finalize and be
>done with it.
Pretty much.
Another reason to avoid finalize is that it is not run on the main
thread! Thus your finalizers must be thread-safe. You can safely call
free(), CFRelease(), DisposeHandle(), and DisposePtr() for example.
On 3/16/09 2:08 PM, Bill Cheeseman said:
>Leopard, NSEvent includes methods to return the associated CGEventRef,
>which is a CFTypeRef-style ivar (but declared as void* for reasons
>that have so far escaped me).
In my 10.5 SDK it is declared as:
- (CGEventRef)CGEvent;
You probably mean this one:
- (const void * /* EventRef */)eventRef;
I suspect it's because they don't want to pull in headers from another
framework. Especially the pariah Carbon.h. :)
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
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