ARC不会dealloc当指针设置为nil（使用工厂方法） [英] ARC does not dealloc when pointer is set to nil (using factory methods)

问题描述

编辑：使用此代码实际发生的问题：

  int main（int argc，const char * argv [ ）
 {
 @autoreleasepool 
 {
 XYZPerson * myPerson = [XYZPerson person]; 
 myPerson = nil; 
 NSLog（@The end。）; 
} 
} 
  

方法'person'是一个工厂方法。 / p>

---

我有以下代码：

 code> int main（int argc，const char * argv []）
 {
 @autoreleasepool 
 {
 XYZPerson * myPerson = [[XYZPerson alloc] init]; 
 myPerson = nil; 
 NSLog（@The end。）; 
} 
} 
  

XYZPerson覆盖dealloc方法， NSLog。我期望上面的代码输出像：

  Dealloc！ 
结束。 
  

但这不是我预期的：

 结束。 
 Dealloc！ 
  

我做错了事或者我误解了ARC的概念吗？

解决方案

ARC保证对象将在编译时自动引用计数。它进一步并且要求代码在算法上完全一致（当在尝试转换时表示为错误，例如 void * 和 id

ARC不是一个垃圾回收器，而是一个垃圾回收器。没有扫描，没有线程，没有停止世界的行为。这意味着以自动循环检测等为代价的更可预测的行为。

ARC保证对象的生命周期将被自动管理，ARC不能保证寿命超过该对象将至少存活至少与代码中使用的一样长，也许更长。

事实上，您可能会看到寿命的变化取决于优化代码级别以及调用的工厂方法是否在ARC与手动保留释放[MRR]源文件中编译。

例如，ARC代码调用一个工厂方法有时可能会将 autorelease 完全。

听起来很可怕，但它不是因为算法的一致性要求。由于不能存在不明确的行为（因为可以在普通的旧MRR中），所以生命周期可能会因为发布而改变。不会影响您的代码。

当然，这意味着不应在 dealloc 方法之间具有顺序依赖性。这不应该是一个繁重的要求，因为在MRR下的 dealloc 方法之间的顺序依赖总是一个讨厌的事情。

Edit: Problem defined below actually occurred with this code:

int main(int argc, const char * argv[])
{
    @autoreleasepool
    {
        XYZPerson *myPerson = [XYZPerson person];
        myPerson = nil;
        NSLog(@"The end.");
    }
}

The method 'person' is a factory method.

---

I have the following code:

int main(int argc, const char * argv[])
{
    @autoreleasepool
    {
        XYZPerson *myPerson = [[XYZPerson alloc] init];
        myPerson = nil;
        NSLog(@"The end.");
    }
}

XYZPerson overrides dealloc method so that it prints out something with NSLog. I expect the code above to output something like:

Dealloc!
The end.

But it is not as I expected:

The end.
Dealloc!

Am I doing something wrong or did I misunderstand the concept of ARC?

解决方案

ARC guarantees that objects will be automatically reference counted at compile time. It goes further and places the requirement that the code be algorithmically fully coherent (which manifests as errors when trying to convert between, say, void* and id via casting -- under ARC, you have to qualify the memory management policy across such casts).

ARC is not a garbage collector; there is no scanning, no threading, and no stop-the-world behavior. This means more predictable behavior at the cost of things like automatic cycle detection.

While ARC guarantees that an object's lifespan will be automatically managed, ARC does not guarantee that lifespan beyond "the object will live for at least as long, maybe longer, than it is used in the code".

In fact, you might see lifespan changes depending on both the optimization level of the code and whether or not the factory method you invoked is compiled in an ARC vs. manual-retain-release [MRR] source file. And the lifespan may change across releases of the compiler and/or runtime.

For example, ARC code calling into a factory method can sometimes short-circuit the autorelease entirely.

Sounds scary, but it isn't because of the algorithmic coherence requirement. Since there cannot be ambiguous behavior (as there can in plain old MRR), that the lifespan might change over releases should not impact your code.

Of course, this means that you should not have order dependencies between dealloc methods. This should not be an onerous requirement as having order dependencies between dealloc methods under MRR was always a nasty thing.

这篇关于ARC不会dealloc当指针设置为nil（使用工厂方法）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！