为什么用myInstance = nil代替self.myInstance = nil? [英] Why myInstance = nil instead of self.myInstance = nil?

查看:77
本文介绍了为什么用myInstance = nil代替self.myInstance = nil?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我为什么要使用(在我的dealloc方法中)?

  1. [myInstance release]而不是[self.myInstance release]
  2. myInstance = nil而不是self.myInstance = nil

虽然我们使用self.myInstance = [[[AClass alloc] init] autorelease]而不是myInstance = [[[AClass alloc] init] autorelease]?

这些做法来自我在网上看到的众多示例.

解决方案

1)[myInstance版本]而不是[self.myInstance版本]

更喜欢前者.

self.myInstance的返回值由实现定义,当子类重写方法myInstance时.您对dealloc期间构造对象的接口的行为不感兴趣(因为子类可能会覆盖并返回除ivar之外的其他值).

您对dealloc感兴趣的是在销毁对象之前释放您拥有的引用.如果子类已覆盖myInstance,则可能:

a)返回一个已经被释放的ivar(在子类中声明)

b)覆盖的实现可能返回一个新创建的自动释放对象

a或b都可能导致过度释放和崩溃(假设其他所有内容均已正确保留/释放).这也说明了为什么在释放ivar后应该将nil分配给它.

这也是如何触发对象复活的经典示例.当您调用的getter/setter的实现在已释放后重新创建其状态时,将发生对象复活.最不令人反感的副作用将导致无害的泄漏.

2)myInstance = nil而不是self.myInstance = nil

再次,选择前者.

形式上的回应看起来很像对#1的回应-原理,副作用和危险也适用于这里.

处理此问题的最安全方法是直接访问ivar:

[myInstance release], myInstance = nil;

因为可能确实存在令人讨厌的副作用(崩溃,泄漏,复活),

可以很容易地避免这些危险,并且可以更轻松地维护您的代码.另一方面,如果人们在使用您的程序时遇到副作用,他们可能会尽可能避免(重新)使用它.

祝你好运

Why would I use (inside my dealloc method)?

  1. [myInstance release] instead of [self.myInstance release]
  2. myInstance = nil instead of self.myInstance = nil

Although we use self.myInstance = [[[AClass alloc] init] autorelease] instead of myInstance = [[[AClass alloc] init] autorelease]?

Those practices are from numerous examples I see on the web.

解决方案

1) [myInstance release] instead of [self.myInstance release]

prefer the former.

the returned value of self.myInstance is defined by implementation when a subclass has overridden the method myInstance. you're not interested in the behaviour of the interface of a constructed object during dealloc (since a subclass may override and return something other than your ivar).

what you are interested in dealloc is releasing the references you own before your object is destroyed. if the subclass has overridden myInstance, then it could:

a) return an ivar (declared in the subclass) that's already been released

or

b) the implementation of the override may return a newly created autoreleased object

either a or b could lead to an over-release and a crash (assuming everything else is correctly retained/released). this also suggests why you should assign nil to the ivar after releasing it.

this is also a classic example of how to trigger object resurrection. object resurrection occurs when an implementation of the getter/setter you call recreates its state after it's already been deallocated. the least offensive side-effect would cause a harmless leak.

2) myInstance = nil instead of self.myInstance = nil

again, prefer the former.

a formal response would look much like the response to #1 -- the rationale, side-effects and dangers apply here as well.

the safest way to handle this is to access the ivar directly:

[myInstance release], myInstance = nil;

because there may be really nasty side-effects (crashes, leaks, resurrection) which may be difficult to reproduce.

these dangers may be easily avoided and your code will be far easier to maintain. on the other hand, if people encounter the side-effects when using your programs, they will probably avoid (re)using it wherever they can.

good luck

这篇关于为什么用myInstance = nil代替self.myInstance = nil?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆