Objective C - Тест для экземпляра объекта, являющегося dealloced/freed

Извлеките имя метода из вашего оператора импорта. например,

import Dan.Vik.disp;

становится:

import Dan.Vik;
7
задан jlpiedrahita 11 June 2009 в 20:06
поделиться

5 ответов

Вы не можете проверить, был ли объект освобожден, поскольку, очевидно, объект больше не существует, чтобы поговорить с ним. Если вы установите для b значение nil при его освобождении (скажем, выполнив self.b = nil ), вы можете проверить на ноль и затем создать объект.

11
ответ дан 6 December 2019 в 06:50
поделиться

Если вы установите переменную среды NSZombieEnabled , освобожденные объекты станут экземплярами NSZombie . Они генерируются при следующем сообщении, что приводит к сбою и сгоранию кода - именно то, что вам нужно для отладки этой ситуации.

http://www.cocoadev.com/index.pl?DebuggingAutorelease

Обновление : Для XCode 4.0 см. Как включить NSZombie в Xcode?

13
ответ дан 6 December 2019 в 06:50
поделиться

Вы можете попробовать поместить сообщения NSLog в метод объектов dealloc . Это по крайней мере скажет вам, когда объект будет выпущен.

0
ответ дан 6 December 2019 в 06:50
поделиться

Если вы сохраните b правильно, он не будет освобожден в условиях нехватки памяти.

То есть, если вы не освобождаете его самостоятельно, в этом случае важно, чтобы вы вручную удалили все ссылки на него перед тем, как вы это сделаете (заменив его на nil)

В этом случае подойдет простая проверка его на значение nil:

  if (nil == b)
  { 
    reallocate b;
  }

Если кажется, что ваши объекты освобождаются автоматически, вам необходимо проверить ваш код, чтобы убедиться, что вы сохранили его в достаточной степени.

2
ответ дан 6 December 2019 в 06:50
поделиться

Поскольку переменная 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 , и он намного эффективнее, чем многократное (де) выделение объектов.

3
ответ дан 6 December 2019 в 06:50
поделиться