Question

I found an implementation of a priority queue that primarily uses CFBinaryHeap to work.

I’m currently using the -fno-objc-arc compiler flag to skip the usage of ARC while compiling these files. I attempted to update this code to take advantage of ARC, though I’ve run into a few snags of understanding.

Is there anyone here who has updated code similar to this for use with ARC?

How do you handle things like free(), and CFRelease()? Can we just get rid of them?

What do you do with the retain and release methods you create for CFBinaryHeapCallBacks?

Do you use __bride or __bridge_transfer to reference the const void * into Objective-C objects? Likewise should you use (__bridge_retained void *) or obj_unretainedPointer() to do the reverse?

Answer 1

ARC basically is a compiler technology that automatically inserts calls to -retain, -release, and -autorelease as needed. It does not remove the need for retains and releases, it just makes them automatic (in the process, optimizing out many that are not required, and playing other tricks to make various common patterns much more efficient than if you did it by hand).

ARC knows nothing about Core Foundation, nor about void* objects, malloc, free, or anything other than ObjC memory management.

This means that as long as you use Core Foundation objects, you should continue to use CFRelease. And if you malloc memory, you should continue to free it.

But…. what if you want to take memory that was created by Core Foundation and transfer it to Cocoa via a toll-free bridge? That’s where __bridge* comes in. One of the best sources of information is the clang docs themselves. A great blog article is Everything you need to know about ARC. It includes many useful links to the definitive information.

But here’s the short answer (from Transitioning to ARC)

NSString   *c = (__bridge_transfer NSString*)my_cfref; // -1 on the CFRef
CFStringRef d = (__bridge_retained CFStringRef)my_id;  // returned CFRef is +1

Using __bridge_transfer logically moves a CF object into Cocoa. Using __bridge_retained logically moves a Cocoa object into CF. You use these when you are really transferring ownership of the object. In the above example, you generally shouldn’t continue using the my_ variables in my opinion. These are particularly useful in cases where you are returning the result out of the function. These should be used for their logical ownership functionality only. Don’t use them as a way to “fake” a manual call to retain or release.

If you just want to have a temporary “bridged” pointer to the object so you can use it in CF or Cocoa without transferring it, then use __bridge. That’s a no-op that says “don’t do any memory management, just let me pretend for the moment that it’s the other kind of object.” If you do a lot of toll-free bridging, you’ll wind up using __bridge quite a lot (making it seem like a small toll…. :D)