Зачем использовать TT_RELEASE_SAFELY в Three20 для iPhone? - PullRequest
Новая
       56

Зачем использовать TT_RELEASE_SAFELY в Three20 для iPhone?

1 голос
/ 25 сентября 2010 
#define TT_RELEASE_SAFELY(__POINTER) { [__POINTER release]; __POINTER = nil; }

Почему три20 считает безопасным назначать ивару ноль после его выпуска?Не безопасно ли пропустить шаг ivar = nil?

Это все, что я нашел: http://github.com/facebook/three20/commit/1b946f475fb28d60e0aafc9ef394050c642c3a5b#commitcomment-115517

Я не думаю, что использую KVO / KVC, ноне совсем уверен.Я читаю об этом сейчас.

Спасибо!

Мэтт

Ответы [ 2 ]

6 голосов
/ 25 сентября 2010

Находясь внутри -dealloc, этот вопрос разделяет гуру Objective-C. прочитайте эту недавнюю запись в блоге например.

Находясь внутри реализации других методов, я лично считаю, что вы не должны сохранять переменную в области видимости после выпуска в первую очередь. Этот код 

   SomeClass* someObject= ...
   ... use someObject ...
   [someObject release]; 
   ... more code ...

может случайно получить доступ к someObject позже в коде, что приведет к сбою. Так что вы можете сказать 

   SomeClass* someObject= ...
   ... use someObject ...
   [someObject release];
   someObject=nil; 
   ... more code ...

было бы лучше, потому что сообщение на nil безвредно. Однако в этом случае вы можете полностью устранить опасность: 

   {
      SomeClass* someObject= ...
      ... use someObject ...
     [someObject release]; 
   }
   ... more code ...

Здесь я использую блок {...} для ограничения области видимости переменной. Тогда использование someObject позже - просто ошибка времени компиляции.

3 голосов
/ 25 сентября 2010

В частности, в случае выпуска иваров в dealloc в сообществе довольно много споров о том, лучше ли устанавливать их на nil после выпуска или нет.

Pro-nil camp считает, что в целом это снижает вероятность сбоя приложения в неудачном случае, когда к объекту обращаются после освобождения или даже во время многопоточных приложений.

Anti-nilЛагерь не считает, что приведенный выше аргумент особенно полезен, потому что они чувствуют, что приложение СЛЕДУЕТ аварийно завершить работу в таком случае, чтобы сделать более очевидным, что ваше приложение имеет дефект (оно обращается к освобожденному объекту).

Это не обязательно наиболее полное резюме позиций, но оно дает вам представление о «противоречиях».

Проблема KVO / KVC несколько отделена, поскольку это аргумент, а не вопрос о том, следует ли устанавливатьivar to nil, но безопасно ли использовать установщик свойства для этого из-за возможногопроблемы с побочными эффектами (например, KVO / KVC).

...