Объекты CF против объектов NS

Ответ 1

Чтобы ответить на ваши вопросы в порядке:

• Какова точка зрения обоих существующих? Есть несколько причин.

  Если вы хотите предоставить API C, например API-интерфейс Carbon, и вам нужны такие вещи, как массивы и словари объектов с подсчетом, вам нужна библиотека, такая как Core Foundation (которая предоставляет CFArray), и, конечно же, это должен иметь C API.

  Если вы хотите писать библиотеки для сторонних разработчиков для использования в Windows (например), вам необходимо предоставить API C.

  Если вы хотите написать низкоуровневую библиотеку, скажем, для взаимодействия с ядром операционной системы, и вам не нужны накладные расходы на обмен сообщениями Objective-C, вам нужен C API.

  Итак, это хорошие причины для создания Core Foundation, чистой библиотеки C.

  Но если вы хотите предоставить более приятный API более высокого уровня в Objective-C, вы хотите, чтобы объекты Objective-C представляли массивы, словари, объекты с подсчетом ссылок и т.д. Поэтому вам нужен Foundation, который является библиотекой Objective-C.

• Когда вы должны использовать тот или иной? Как правило, вы должны использовать классы Objective-C (например, NSArray), когда это возможно, потому что интерфейс Objective-C более приятен в использовании: myArray.count (или [myArray count]) легче читать и писать, чем CFArrayGetCount(myArray). Вы должны использовать Core Foundation API только тогда, когда вам действительно нужно: когда вы находитесь на платформе, которая не имеет Objective-C, или когда вам нужны функции, которые предоставляет Core Foundation API, но объекты Objective-C отсутствуют. Например, вы можете указать обратные вызовы при создании CFArray или CFDictionary, которые позволяют хранить объекты, не связанные с ссылкой. Классы NSArray и NSDictionary не позволяют вам это делать - они всегда предполагают, что вы храните объекты с подсчетом ссылок.

• Являются ли объекты CF только унаследованными объектами? Не за что. Фактически, Nextstep существовал в течение многих лет только с библиотекой Foundation Objective-C и без (публичной) библиотеки Core Foundation. Когда Apple нуждалась в поддержке API Carbon и API Cocoa поверх тех же устройств операционной системы нижнего уровня, они создали (или сделали общедоступным) Core Foundation для поддержки обоих.

Кстати, некоторые из Core Foundation являются open source. Вы можете найти часть с открытым исходным кодом для Mac OS X 10.10.5 здесь: https://opensource.apple.com/source/CF/CF-1153.18/. Я нашел исходный код CFRunLoop и CFStream очень информативным.

Ответ 2

Core Foundation является C API для множества общих структур данных. Большинство этих структур данных имеют эквиваленты в Cocoa, но не все из них. Большинство из них, которые эквивалентны, являются бесплатными мостами, что позволяет использовать их взаимозаменяемо, но не все из них.

Беспроблемное мостовое соединение - очень умный трюк. Если вы хотите получить подробные сведения, см. Сообщение ridiculous_fish, на которое указывает @Matt Wilding. Он наиболее авторитетный по этому вопросу (и большое влияние на iOS: PTL глава 19, в котором также объясняется, как все это работает). Но это не имеет большого значения для большинства целей. Как отмечает Мэтт, вы можете вообще притворяться, что NSArray совпадает с CFArrayRef. Во многих случаях это не так, но иногда это правда и достаточно близко в большинстве случаев. Это то же самое, что сказать, что @"stuff" совпадает с NSString, содержащим stuff. Это в основном верно, но не совсем.

Когда OS 9 переместилась в OS X, было очень удобно предоставить C доступ к Objective-C -подобным структурам данных. Многие низкоуровневые структуры сегодня выставляют C API для повышения производительности. Вы не должны думать о том, что CF - это "наследие" или "внутреннее". Вы должны думать об этом как о низком уровне, и вы должны использовать его только тогда, когда вам нужна сила, которую он предоставляет, или имеют дело с низкоуровневой структурой, которая требует этого.

Объекты CF часто более гибкие, чем их аналоги NS. Например, CFDictionaryRef может содержать не-объекты ключи и значения, а NSDictionary не может. (Конечно, они беспошлины мосты, поэтому вы можете создать не сохраняющийся CFDictionaryRef, а затем рассматривать его как NSDictionary. Трудно это....)

Поскольку Apple выпускает новые фреймворки, вы заметите, что они часто выставляют C API сначала, а затем добавляют API Objective-C. Это является основанием для того, чтобы изучить Core Foundation, даже если вы не используете его каждый день. Но когда это возможно, вы обычно должны использовать ObjC.

Ответ 3

Там какая-то история на этот вопрос. Основной фонд - это мозг операции. Он написан в основном на C. Он был создан с приобретением Apple NEXT и их API и многим им обязан. Классы NS * часто представляют собой абстрактные интерфейсы Objective C, созданные поверх типов CF *. Итак, когда вы спрашиваете, почему существуют как CFArray, так и NSArray, ответ заключается в том, что они на самом деле этого не делают. NSArrays - CFArrays, NSStrings - CFStrings и т.д. Поэтому возможен бесплатный мостовой доступ.

Для более интересного и подробного чтения я бы назвал вас этот пост в блоге.

Ответ 4

CF означает CoreFoundation. Открытые объекты с CF в их именах являются просто регулярными объектами Core Foundation, написанными на C. Все объекты бесплатны для мостов с их друзьями Cocoa Touch Foundation в Objective-C. Они, как правило, непрозрачные указатели.

NS означает NextStep, которая была старой ОС, на которой была построена Mac OS X. Объекты с префиксом NS обычно пишутся целиком в Objective-C или C или даже в С++.

Это действительно зависит от того, что вам нужно для каждого объекта. Мне, безусловно, легче работать в чистом Objective-C с NSString, тогда мне нужно работать в сочетании C и Objective-C с CFString, но есть некоторые вещи, которые объекты CF могут делать, что объекты NS просто могут " t (в основном материал с очень низким уровнем). Объекты CF также намного больше влияют на Ref, мутации и проверки, чем их коллеги NS.

(Для справки в будущем существует еще несколько префиксов: CG для CoreGraphics, UI для UIKit, QL для QuickLook, AV для AVFoundation, MP для MediaPlayer, MF для MessageFoundation, GL для GLKit и MK для MapKit) (if Я пропустил любой, я с удовольствием отредактирую).