Извлеките имя метода из вашего оператора импорта. например,
import Dan.Vik.disp;
становится:
import Dan.Vik;
Вы не можете проверить, был ли объект освобожден, поскольку, очевидно, объект больше не существует, чтобы поговорить с ним. Если вы установите для b
значение nil при его освобождении (скажем, выполнив self.b = nil
), вы можете проверить на ноль и затем создать объект.
Если вы установите переменную среды NSZombieEnabled
, освобожденные объекты станут экземплярами NSZombie
. Они генерируются при следующем сообщении, что приводит к сбою и сгоранию кода - именно то, что вам нужно для отладки этой ситуации.
http://www.cocoadev.com/index.pl?DebuggingAutorelease
Обновление : Для XCode 4.0 см. Как включить NSZombie в Xcode?
Вы можете попробовать поместить сообщения NSLog в метод объектов dealloc
. Это по крайней мере скажет вам, когда объект будет выпущен.
Если вы сохраните b правильно, он не будет освобожден в условиях нехватки памяти.
То есть, если вы не освобождаете его самостоятельно, в этом случае важно, чтобы вы вручную удалили все ссылки на него перед тем, как вы это сделаете (заменив его на nil)
В этом случае подойдет простая проверка его на значение nil:
if (nil == b)
{
reallocate b;
}
Если кажется, что ваши объекты освобождаются автоматически, вам необходимо проверить ваш код, чтобы убедиться, что вы сохранили его в достаточной степени.
Поскольку переменная b
полностью внутренняя по отношению к классу A
, и не объявлена как @public
(по умолчанию @protected
), лучший способ узнать, освобожден ли b
, - освободить его и установить указатель на nil
. Таким образом, вы можете просто проверить if (b == nil)
и при необходимости создать новый экземпляр.
Однако более серьезный вопрос заключается в том, какова истинная природа и поведение памяти b
есть. Вы заявляете, что «объект B может быть освобожден на нижних уровнях памяти», но не объясняете почему. Если вы используете стандартные идиомы для сохранения-выпуска в Objective-C, я бы подумал, что A будет тем, кто определит, следует ли освобождать B, поскольку он создает новый экземпляр. Если вы не собираетесь, чтобы A принимал такие решения, разрешение ему выделить новый B приведет к путанице владельцев и ошибкам памяти в будущем.
Если A не отвечает за B, и если вы используете Leopard (или выше) и включили сборку мусора, вам может потребоваться слабая ссылка для обнуления . Это объявляется с использованием __ weak
перед объявлением переменной экземпляра и не мешает сборщику мусора собрать объект, на который он указывает. (По умолчанию используется «сильная» ссылка, и сборщик мусора не освобождает объект, который он может отследить от корня, только по сильным ссылкам.) Кроме того, GC автоматически установит для вас слабые ссылки на 0, если / когда объект является освобожден.
Возвращение к " Если причиной освобождения b
является то, что экземпляры B растут со временем (например, кеш с необязательными элементами), было бы гораздо лучше иметь способ очистить B. Например, изменяемые коллекции в У Foundation есть метод -removeAllObjects
. Такой подход позволит избежать большей части путаницы относительно того, существует ли еще b
, и он намного эффективнее, чем многократное (де) выделение объектов.
b
является то, что экземпляры B растут со временем (например, кеш с необязательными элементами), было бы гораздо лучше иметь способ очистить B. Например, изменяемые коллекции в У Foundation есть метод -removeAllObjects
. Такой подход позволит избежать большей части путаницы относительно того, существует ли еще b
, и он намного эффективнее, чем многократное (де) выделение объектов.