Objective-c: Why Core Foundation variables need explicit release in ARC?

Question

When I think about ARC there is no overhead of release. But once come across the Core Foundation variables, they need to release in ARC also.

Though the ARC rules are different for both NS.. and CF.., is there anything specific reason for not supporting CF.. in ARC ?

Answer 1

When I think about ARC there is no overhead of release.

I assume you mean "I don't have to worry about release." There often is some performance overhead, though the compiler can sometime optimize it out.

Though the ARC rules are different for both NS.. and CF.., is there anything specific reason for not supporting CF.. in ARC ?

Many Core Foundation objects are managed by ARC, and the number of them keeps increasing. You can tell whether a particular function supports ARC by looking in the header for CF_IMPLICIT_BRIDGING_ENABLED. If you see that, then the functions return ARC-compatible CF objects. In iOS 8, for instance, many Core Graphics functions were added to the list. (I don't want to overstate this; I'm not saying that today you don't today CFRelease on these. I'm saying they're setup to be managed by ARC, they're managed by ARC in Swift, and they may eventually be handled directly in ObjC without needing CFRelease.)

The reason CF objects aren't by default managed is that someone had to go through and verify (audit) that every function conforms to the Create Rule naming conventions or that they are correctly annotated for their exceptions. That's fairly tedious work, and Apple has spread it out over several releases. But you should see this get better and better over time.

Kazuki is correct that you can't put ARC-managed objects in a struct or union, but that doesn't usually impact Core Foundation.

BTW, CF_IMPLICIT_BRIDGING_ENABLED is just a wrapper around the arc_cf_code_audited clang pragma. This is explained in the ARC docs, 7.8.1 Auditing of C retainable pointer interfaces.

Answer 2

Core Foundation is a pure C library. Thus, at least, there is a reason that ARC can not support Core Foundation object directly.

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership-qualified-fields-of-structs-and-unions

4.3.5 Ownership-qualified fields of structs and unions

A program is ill-formed if it declares a member of a C struct or union to have a nontrivially ownership-qualified type.

Rationale

The resulting type would be non-POD in the C++ sense, but C does not give us very good language tools for managing the lifetime of aggregates, so it is more convenient to simply forbid them. It is still possible to manage this with a void* or an __unsafe_unretained object.

So LLVM compiler cannot handle the lifetime of Core Foundation objects in structs and unions as well as this explanation, due to C does not give us very good language tools for managing the lifetime of aggregates.