Сборка «мусора»

Время выполнения Objective C исследует на запуске изображение выполнения, чтобы определить, работать ли со сборкой «мусора» или нет. Каждый объектный файл имеет информационный раздел, и они должны все согласиться для выполнения продолжиться. Стандартная компиляция приводит к информационному разделу, указывающему, что не присутствует никакая возможность GC. Компиляция с -fobjc-gc указывает, что и GC и сохраняет/выпускает логику, присутствует. Компиляция с -fobjc-gc-only указывает, что только присутствует логика GC. Исполнимая программа неGC, пытающаяся загрузить платформу только для gc, перестанет работать, как будет GC способная исполнимая программа что attemps для загрузки GC неспособная платформа (или пакет).

Компилятор использует три функции «помощника» для присвоений сильных указателей на, собрал «мусор» память в глобальную память (objc_assign_global), собрал «мусор» память «кучи» (objc_assign_ivar), или в неизвестную память (objc_assign_strongCast). Для присвоений слабых указателей это использует objc_assign_weak и для чтений это использует objc_read_weak.

При копировании памяти оптом в собравший «мусор» блок необходимо использовать API objc_memmove_collectable(void *dst, const void *src, size_t size).

objc_assign_global_error

objc_assign_ivar_error

objc_exception_during_finalize_error

auto_zone_resurrection_error

auto_refcount_underflow_error

Свойства

Синтаксис для свойств Objective-C был перестроен начиная с WWDC 2006. См. документацию свойства (Свойства) для подробных данных.

Таким образом, @property(attributes) type name представляет неявное объявление «метода get» и метода «метода set» (если свойство только для чтения не требуют) для названной «переменной». setter= и getter= атрибуты позволяют указывать имена методов, иначе метод «имени» и «setName»: метод неявно объявляется. Их можно также явно назвать.

По умолчанию свойства присваиваются, когда установлено. Для объектов под неGC это часто неправильно, и предупреждение выпущено, если явно не называют семантическое присвоение. Существует три выбора: assign, для несохраненных ссылок на объект; copy, для объектов, копирующихся и неявно сохраняющихся; и retain, для объектов, требующих быть сохраненным, когда установлено.

Доступ к свойствам является атомарным по умолчанию. Это тривиально под GC для почти всего и также тривиально под неGC для всего кроме объектов и структур. В определенном атомарном доступе к сохраненным объектам под неGC условия могут быть дорогими. Также, a nonatomic атрибут свойства доступен.

Указатели могут быть сохранены строго под GC путем объявления их __strong, и они могут обнулять слабый путем объявления их __weak.

Реализации для свойств могут быть предоставлены компилятором и время выполнения с помощью @synthesize оператор в @implementation раздел класса (или расширение класса). Компилятор ожидает переменную экземпляра того же имени как свойство. Если Вы хотите использовать другое имя, Вы предоставляете его к @synthesize оператор.

В частности компилятор и время выполнения реализует средства доступа к сохраненным объектам при помощи атомарного, сравнивают и подкачивают инструкции. Чрезвычайно опасно непосредственно получить доступ к атомарному свойству объекта через свою переменную экземпляра, так как другой поток мог бы изменить свое значение непредсказуемо. Как таковой компилятор предупредит Вас о таких незащищенных доступах. Время выполнения, фактически, будет временно использовать младший значащий бит переменной экземпляра как временная блокировка при сохранении нового значения и выпуске старого. Прямому использованию атомарной переменной экземпляра под неGC строго обескураживают.

Пакеты загрузки и разгрузки

Так как OS X v10.4 это был возможен разгрузить пакеты, содержащие Objective C. Никакая попытка не предпринята для предотвращения этого, если объекты все еще присутствуют для разгруженных классов. Подклассы классов, загруженных в пакетах, особенно уязвимы.

Метод и атрибуты класса

Objective C теперь поддерживает некоторые атрибуты gcc для методов Objective C. Синтаксически, атрибуты для метода следуют за объявлением метода, и атрибуты для параметра метода находятся между типом параметра и названием параметра. Поддерживаемые атрибуты включают:

• Осуждение и доступность, включая AvailabilityMacros.h

  - (void)method:(id)param __attribute__((deprecated));

• Неиспользованные параметры

  - (void)method:(id) __attribute__((unused)) param;

• Параметры сигнальной метки, включая NS_REQUIRES_NIL_TERMINATION

  - (void)methodWithObjects:(id)obj, ... NS_REQUIRES_NIL_TERMINATION;

Objective C также поддерживает некоторые атрибуты gcc для классов Objective C. Синтаксически, атрибуты для класса предшествуют классу @interface объявление. Поддерживаемые атрибуты включают:

• Осуждение и доступность, включая AvailabilityMacros.h

  __attribute__((deprecated))

  @interface MyDeprecatedClass : SomeSuperclass

• Видимость

  __attribute__((visibility("hidden")))

  @interface MyPrivateClass : SomeSuperclass

Переменные экземпляра @package

@package новый класс защиты переменной экземпляра, как @public и @protected. @package переменные экземпляра ведут себя следующим образом:

• @public в 32-разрядном;

• @public в 64-разрядном, в платформе, определившей класс;

• @private в 64-разрядном, вне платформы, определившей класс.

В 64-разрядном, символе переменной экземпляра для @package ivar не экспортируется, таким образом, любая попытка использовать ivar извне платформы, определившей класс, перестанет работать с ошибкой ссылки. См. «64-разрядное Управление доступом Класса и Переменной экземпляра» для больше о символах переменной экземпляра.

Изменения API во время выполнения

Интерфейс C ко времени выполнения Objective C (в <objc/*.h>) изменился значительно. Выделения включают:

• Почти все структуры осуждаются, включая struct objc_class. Предоставлены функциональные замены для большинства из них.

• class_poseAs осуждается. Используйте функции манипулирования списком методов вместо этого.

• class_nextMethodList осуждается. Использовать class_copyMethodList вместо этого.

• class_addMethods осуждается. Использовать class_addMethod вместо этого.

• objc_addClass осуждается. Использовать objc_allocateClassPair и objc_registerClassPair вместо этого.

• В целом все устаревшие (deprecated) объявления отсутствуют в 64-разрядном.

• API в objc/objc-runtime.h и objc/objc-class.h находится теперь в objc/runtime.h и objc/message.h. Старые заголовочные файлы просто #include новые.

64-разрядный ABI

64-разрядный Objective C ABI обычно непохож на 32-разрядный ABI. Новый ABI обеспечивает новые функции, лучшую производительность, и улучшил будущую адаптируемость. Все аспекты 64-разрядного ABI являются частными и подвергаются будущему изменению. Предстоящая документация опишет ABI для использования компиляторов и инструментов разработчика только.

64-разрядное управление доступом класса и переменной экземпляра

В 64-разрядном Objective C, управлении доступом для классов и каждой переменной класса и переменной экземпляра связали символ с ним. Все использование переменной класса или переменной экземпляра ссылается на этот символ. Эти символы подвергаются управлению доступом компоновщиком.

Результат - то, что более строго осуществляется доступ к частным классам и ivars. Незаконное использование частного ivar может перестать работать с ошибкой ссылки. Платформы, обеспечивающие классы и ivars, должны правильно экспортировать свои символы. В частности платформы, созданные с -fvisibility=hidden или список экспорта компоновщика, возможно, должен быть изменен.

Классификационные знаки имеют имена формы _OBJC_CLASS_$_ClassName и _OBJC_METACLASS_$_ClassName . Классификационный знак используется клиентами, отправляющими сообщения в класс (т.е. [ClassName someMessage]). Символ метакласса используется клиентами, разделяющими класс на подклассы.

По умолчанию классификационные знаки экспортируются. Они затронуты флагами видимости символа gcc, таким образом, -fvisibility=hidden сделает классификационные знаки неэкспортируемыми. Компоновщик распознает старое имя символа .objc_class_name_ClassName в списках экспорта компоновщика и переводит его в эти символы.

Видимость единого класса может быть изменена с помощью атрибута.

__attribute__((visibility("hidden")))

@interface ClassName : SomeSuperclass

Для классов с»default«видимость, классификационные знаки экспортируются, и ivar символы обрабатываются, как описано ниже. Для классов со «скрытой» видимостью все не экспортируются классификационные знаки и ivar символы.

Символы Ivar имеют форму _OBJC_IVAR_$_ClassName.IvarName . ivar символ используется клиентами, считавшими или пишущими ivar.

По умолчанию, ivar символы для @private и @package ivars не экспортируются, и ivar символы для @public и @protected ivars экспортируются. Это может быть изменено списками экспорта, -fvisibility, или видимость приписывает на классе. Атрибуты видимости на отдельном ivars в настоящее время не поддерживаются.

64-разрядные нехрупкие переменные экземпляра

Все переменные экземпляра в 64-разрядном Objective C нехрупки. Т.е. существующий скомпилированный код, использующий ivars класса, не повредится, когда класс или суперкласс изменят свое собственное ivar расположение. В частности классы платформы могут добавить новый ivars, не повреждая подклассы, скомпилированные против предыдущей версии платформы.

Ivars может быть добавлен или переупорядочен свободно; существующие пользователи переупорядоченного ivar адаптируются прозрачно. Другие изменения ivar безопасны за исключением того, что они повредят любых существующих пользователей ivar: удаление ivar, переименование ivar, перемещение ivar к различному классу и изменения типа ivar.

Не использовать @defs. ivar расположение, которое это представляет, не может адаптироваться для суперклассифицирования изменений.

Не использовать sizeof(SomeClass). Использовать class_getInstanceSize([SomeClass class]) вместо этого.

Не использовать offsetof(SomeClass, SomeIvar). Использовать ivar_getOffset(class_getInstanceVariable([SomeClass class], "SomeIvar")) вместо этого.

64-разрядный стоивший нулем C ++-Compatible исключения

В 64-разрядном была переписана реализация исключений Objective C. Новая система обеспечивает «стоившие нулем» блоки попытки и функциональную совместимость с C++.

«Стоившие нулем» блоки попытки не подвергаются никакому штрафу времени при вводе блока @try, в отличие от 32-разрядного, который должен вызвать setjmp() и другой дополнительный бухгалтерский учет. С другой стороны, фактически выдача исключения является намного более дорогой. Для лучшей производительности в 64-разрядном исключения должны быть выданы только в исключительных случаях.

Платформы Какао требуют, чтобы все исключения были экземплярами NSException или его подклассы. Не бросайте объекты других типов.

Платформы Какао обычно не безопасны от исключения. Их общий образец - то, что исключения резервируются для ошибки программиста только, и программа должна выйти вскоре после ловли такого исключения. Будьте осторожны при выдаче исключений через платформы Какао.

В 64-разрядных, исключениях C++ и Objective C исключения являются взаимодействующими. В частности деструкторы C++ и Objective C @finally блоки соблюдают при раскручивании любого исключения и пунктов выгоды по умолчанию —catch (...) и @catch (...)— в состоянии поймать и повторно бросить любое исключение.

Objective C @catch (id e) выгоды любое исключение Objective C, но никакие исключения C++. Использовать @catch (...) поймать все, и @throw; повторно бросить перехваченные исключительные ситуации. @catch (...) позволен войти 32-разрядный, и имеет тот же эффект там как @catch (id e).