Почему объекты Objective-C должны быть динамически распределены?

Question

Почему объекты Objective-C должны быть динамически распределены? Почему я должен сделать это указателем на объект, в отличие от C ++, я могу создать их в стеке? Спасибо.

Answer 1

Основная причина: не зная, какой размер стека зарезервировать.

Существующие соглашения и использование также затрудняют поднятие ограничения.

В этом случае динамический обмен сообщениями не имеет значения, так как установление правильного «vtable» при инициализации тривиально.

В C ++ размер объекта стека всегда известен (и если это неправильно, вы знаете, чего ожидать). Последовательность objc alloc/init может вернуть любой из нескольких типов - каждый с разными размерами (это по сути фабрика) или вообще ничего.

Размер также может варьироваться во время выполнения (например, вы можете добавить поля в класс во время выполнения).

Обновление 1

Мне было любопытно об этом, поэтому я сделал небольшую программу испытания в качестве доказательства концепции.

Я смог внедрить простую иерархию класса OBJC на основе стека, которая также реализовала хорошую часть NSObjectИнтерфейс - конечно, пропустить интерфейсы отсчета и динамического распределения, поскольку это не связано с доказательством концепции. Во всяком случае, моя простая иерархия классов была нет Полностью совместимый с классом или протоколом NSOBject, поэтому это не то, что следует использовать, где ожидаются типы NSOBject по очевидным причинам. Следовательно, это является Возможно (и не особенно сложно) для этого, если вы действительно хотите объекты OBJC на основе стека.

Вам не нужно делать что -то отличное от C ++, чтобы зарезервировать пространство стека. Размер стопки для резерва все еще является ограничением в некоторых областях (рассмотрите заводские методы, кластеры классов и т. Д.).

Есть также несколько функций выполнения, которые не будут работать по умолчанию. Лучшим примером здесь является возможность добавлять ivars во время выполнения. На самом деле вы могли бы выполнить эту функциональность, если вам это нужно. Я не беспокоился об этом упражнении.

Естественно, базовый интерфейс может принять несколько отклонений - одно отклонение, которое я сделал для развлечения, - это добавление возможности обмена реализациями (типом) живого объекта.

веселиться

Обновление 2

Оказывается, GCC принимает доказательство концепции, которую я написал. К сожалению, это было запрещено в Clang из -за проблем/опасностей, которые можно встретить при резервировании правильного размера (учитывая динамические особенности языка ...). Пример: Clang запрещает sizeof(NSObject). Анкет Ну что ж.

Answer 2

Objective-C-это динамичный язык, что означает, что все в нем может измениться во время выполнения. Объект класса объекта создается только тогда, когда он загружен из исполняемого файла, и он может быть изменен по категориям. Кроме того, переменные экземпляра CAN CAN CAN для свойств. Поскольку так много о объекте может измениться после компиляции, его нельзя создать, пока он не будет использован.

Answer 3

Это связано с тем, как Objective-C использует динамическую или позднюю привязку. В отличие от C ++, где у вас всегда есть выбор между вызовом функции класса по его объекту или через указатель одного и того же класса или даже суперкласса. В последнем случае требуется полиморфизм.

Однако в Objective-C всегда существует способность определять правильную функцию во время выполнения. Разница в том, что, например, в C ++ компилятор должен убедиться, что используемая функция существует, тогда как в Objective-C компилятор на самом деле не заботится, система времени выполнения решает только.