Objective-c: Why do Core Foundation variables need to be explicitly released in ARC?

Question

When I think of ARC, there is no release overhead. But as soon as they come across Core Foundation variables, they should also be released in ARC.

Although ARC rules differ for NS.. and CF.. , is there any specific reason for supporting CF.. in ARC?

Answer 1

When I think of ARC, there is no release exemption.

I assume that you mean "I do not need to worry about the release." Often there are some performance overheads, although the compiler may someday optimize it.

Although ARC rules are different for NS .. and CF .., is there any specific reason for abandoning CF .. in ARC?

Many Core Foundation objects are managed by ARC, and their number is increasing. You can determine if a particular ARC function supports by looking at the header for CF_IMPLICIT_BRIDGING_ENABLED . If you see this, the functions return ARC-compliant CF objects. In iOS 8, for example, many Core Graphics features were added to the list. (I don’t want to exaggerate, I’m not saying that you don’t have CFRelease today. I’m saying that they are configured to manage ARC, they are managed by ARC in Swift, and ultimately they can be processed directly in ObjC without the need for CFRelease . )

The reason that CF objects are not managed by default is because someone had to go through a check (revision) so that each function complies with the Create Rule naming conventions or that they are properly annotated for their exceptions. This is a rather tedious job, and Apple has extended it to several releases. But you should see that over time things get better and better.

Kazuki is right that you cannot put ARC objects in a structure or union, but that usually does not affect the Core Foundation.

BTW, CF_IMPLICIT_BRIDGING_ENABLED is just a wrapper around the pragma arc_cf_code_audited clang. This is explained in the ARC docs, 7.8.1 Listening to C stored pointer interfaces .

Answer 2

Core Foundation is a pure C library . Therefore, at least there is a reason ARC cannot directly support the Core Foundation object.

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

4.3.5 Own fields of structures and unions

A program is poorly formed if it declares a member of a structure or association C to have a non-trivial type of ownership.

Justification

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

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