当我想到 ARC 时，没有发布的开销。
但是一旦遇到Core Foundation 变量，它们也需要在 ARC 中发布。
虽然NS.. 和CF.. 的ARC 规则不同，但在ARC 中不支持CF.. 有什么具体原因吗？
【问题讨论】：
标签： ios objective-c iphone automatic-ref-counting
当我想到 ARC 时，没有发布的开销。
我假设您的意思是“我不必担心释放”。尽管编译器有时可以对其进行优化，但通常会产生一些性能开销。
虽然 NS.. 和 CF.. 的 ARC 规则不同，但在 ARC 中不支持 CF.. 有什么具体原因吗？
许多 Core Foundation 对象由 ARC 管理，并且数量不断增加。您可以通过查看 CF_IMPLICIT_BRIDGING_ENABLED 的标头来判断特定函数是否支持 ARC。如果你看到了，那么这些函数会返回与 ARC 兼容的 CF 对象。例如，在 iOS 8 中，许多 Core Graphics 函数被添加到列表中。 （我不想夸大其词；我并不是说今天你今天不会CFRelease 这些。我是说它们设置为由 ARC 管理，它们由 Swift 中的 ARC 管理，并且它们可能最终直接在 ObjC 中处理，而不需要CFRelease。）
默认情况下不管理 CF 对象的原因是有人必须通过并验证（审核）每个函数都符合创建规则命名约定，或者它们的注释是否正确例外。这是相当乏味的工作，Apple 已将其分发到多个版本中。但随着时间的推移，您应该会看到这种情况越来越好。
Kazuki 是正确的，您不能将 ARC 管理的对象放在结构或联合中，但这通常不会影响 Core Foundation。
顺便说一句，CF_IMPLICIT_BRIDGING_ENABLED 只是 arc_cf_code_audited clang pragma 的包装。这在 ARC 文档 7.8.1 Auditing of C retainable pointer interfaces 中进行了解释。
【讨论】：
核心基金会是a pure C library。因此，至少，ARC 不能直接支持 Core Foundation 对象是有原因的。
4.3.5 结构体和联合体的所有权限定字段
如果程序将 C 结构或联合的成员声明为具有非平凡的所有权限定类型，则该程序是非良构的。
基本原理
生成的类型在 C++ 意义上是非 POD，但 C 没有给出 我们是管理聚合生命周期的非常好的语言工具，所以 简单地禁止它们更方便。还是可以的 使用 void* 或 __unsafe_unretained 对象进行管理。
因此，由于C does not give us very good language tools for managing the lifetime of aggregates，LLVM 编译器无法处理结构和联合中 Core Foundation 对象的生命周期以及此解释。
【讨论】：