Objective-c：為什么Core Foundation變量需要在ARC中顯式發布？

Question

當我想到ARC時，沒有發布的開銷。 但是一旦遇到Core Foundation變量，它們也需要在ARC中發布。

盡管NS..和CF..的ARC規則不同，但是是否有什么具體的原因不支持ARC中的CF.. ？

Answer 1

當我想到ARC時，沒有發布的開銷。

我假設您的意思是“我不必擔心釋放”。 盡管編譯器有時會對其進行優化，但通常會存在一些性能開銷。

盡管NS ..和CF ..的ARC規則都不同，但是是否有任何特定原因不支持ARC中的CF ..？

許多核心基礎對象由 ARC管理，以及它們的數量不斷增加。 通過查看CF_IMPLICIT_BRIDGING_ENABLED的標頭，可以判斷特定功能是否支持ARC。 如果看到，函數將返回ARC兼容的CF對象。 例如，在iOS 8中，許多核心圖形功能已添加到列表中。 （我不想誇大這一點；我並不是說今天您今天不對這些進行CFRelease 。我是說它們已設置為由ARC管理，它們由Swift中的ARC管理，並且他們最終可能會直接在ObjC中處理，而無需CFRelease 。）

CF對象默認情況下不受管理的原因是，必須有人檢查並驗證（審核）每個函數均符合“創建規則”命名約定，或為它們的異常正確注解。 這項工作相當繁瑣，Apple已將其擴展到多個版本中。 但是隨着時間的流逝，您會發現這種情況越來越好。

Kazuki是正確的，您不能將ARC管理的對象放在結構或聯合中，但這通常不會影響Core Foundation。

順便說一句， CF_IMPLICIT_BRIDGING_ENABLED只是arc_cf_code_audited注的包裝。 ARC文檔7.8.1對C可保留指針接口進行審核中對此進行了說明。

Answer 2

Core Foundation是一個純C庫 。 因此，至少由於某種原因，ARC無法直接支持Core Foundation對象。

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

4.3.5結構和工會的所有權限定字段

如果程序聲明C結構或聯合的成員具有非平凡的所有權限定類型，則該程序格式錯誤。

基本原理

從C ++的角度來看，結果類型將是非POD，但是C不能為我們提供很好的語言工具來管理聚合的生存期，因此簡單地禁止使用它們會更方便。 仍然可以使用void *或__unsafe_unretained對象進行管理。

因此LLVM編譯器無法處理結構和聯合中的Core Foundation對象的生存期以及這種解釋，因為C does not give us very good language tools for managing the lifetime of aggregates 。