1 
#define TT_RELEASE_SAFELY(__POINTER) { [__POINTER release]; __POINTER = nil; }

为什么three20认为释放后将ivar分配给nil是安全的？省略该ivar = nil步骤是否不安全？

这就是我发现的全部：http: //github.com/facebook/three20/commit/1b946f475fb28d60e0aafc9ef394050c642c3a5b#commitcomment-115517

我不认为我在使用 KVO/KVC，但我不太确定。我现在正在阅读它。

谢谢！

马特

4

2 回答 2

6

在里面时-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 ...

在这里，我使用{...}块来限制变量的范围。那么使用someObjectlater 简直就是编译时错误。

于 2010-09-25T04:57:47.747 回答
3

特别是对于发布 ivars 的情况，社区中dealloc存在相当多的争论，即nil在发布后是否将其设置为更好。

pronil 阵营认为，一般来说，它使应用程序不太可能在对象被释放后访问的不幸情况下崩溃，甚至在多线程应用程序的情况下也是如此。

反零阵营并不认为上述论点特别有用，因为他们认为应用程序应该在这种情况下崩溃，从而更明显地表明您的应用程序存在缺陷（它正在访问已释放的对象）。

这不一定是最全面的立场总结，但它让您了解所涉及的“争议”。

KVO/KVC 问题有些不同，因为这不是关于是否将 ivar 设置为 nil 的争论，而是由于可能的副作用问题（如 KVO/KVC）使用属性的 setter 是否安全.

于 2010-09-25T04:49:27.473 回答