我应该使用 self.释放时

发布于 2024-12-07 19:11:19 字数 273 浏览 0 评论 0原文

当我定义变量时,我有一大堆@property(nonatomic,retain)内容,我想知道:

在我的dealloc方法中,我应该释放它们[myGreatVariable release];[self.myGreatVariable release];。目前他们是按照前一种方式完成的。这到底有多重要?从现在开始养成这样做的习惯是否很好,或者我应该回去并更改我所有课程中的所有内容,因为事情实际上并没有发布。

I have a whole bunch of @property (nonatomic, retain) stuff going on when I'm defining my variables and i want to know:

In my dealloc method, should i release them [myGreatVariable release]; or [self.myGreatVariable release];. They are currently done in the former way. And how much does this really matter? Is it just good to get in the habit of doing this from now on, or should I go back and change all of them in all of my classes because things aren't actually getting released.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

眼眸里的那抹悲凉 2024-12-14 19:11:19

不要使用[self.myGreatVariable release]。正如丹尼尔指出的那样,它可以在这种情况下工作,但它是最“混蛋”的版本,并且会在 -dealloc 之外的任何地方做错误的事情,可能会留下一个属性中的垃圾引用。

您应该选择其中之一并对其进行标准化:

  1. [myGreatVariable release];
  2. self.myGreatVariable = nil;

(该选择很大程度上取决于个人喜好。我只使用dealloc 中的第一种形式,因为 setter 有时很重要并且有副作用,而 dealloc 的目标是高效、明确地摆脱所有资源,而不是得到由于意外的状态变化而被绊倒。)

Don't use [self.myGreatVariable release]. As Daniel notes, it will work in this context, but it is the most "bastardized" version, and would do the wrong thing anywhere outside -dealloc by likely leaving around a garbage reference in a property.

You should choose one of, and standardize on, either:

  1. [myGreatVariable release];
  2. self.myGreatVariable = nil;

(The choice is largely a personal preference. I only use the first form in dealloc, because setters are sometimes nontrivial and have side-effects, and the goal of dealloc is to get efficiently and clearly get rid of all the resources, not to get tripped up with accidental state changes.)

来世叙缘 2024-12-14 19:11:19

如果你在 dealloc 中,那没关系,尽管前者效率更高一些。但是您还有第三种选择,即 self.myFairlyGoodVariable = nil;,它依赖于 setter 方法来进行释放(尽管效率低了两到三个位)。

我怀疑你会发现关于你应该做什么的不同论点。有些人认为您应该使用实例变量(无 self.)来进行所有读取访问。其他人会认为您应该在几乎所有地方都使用属性访问(即使用 self.)。我倾向于属于后者,但我可以接受另一方的论点。

不过,保持相当一致很重要。如果你与其他人一起工作,如果你能为此制定一个团队“标准”,那就太好了。

(我喜欢做的一件事是将 dealloc 方法放在 .m 文件的顶部,而不是放在它通常结束的底部。这样你就更有可能记得更新添加/更改属性和关联的 @synthesize 语句时的 dealloc 方法。)

If you're in dealloc it doesn't matter, though the former is an itty bit more efficient. But you have the 3rd option of doing self.myFairlyGoodVariable = nil;, which relies on the setter method to do the release (though two or three itty bits less efficiently).

I suspect you'll find different arguments for what you should do. Some folks argue you should use the instance variable (sans self.) for all read accesses. Others will argue that you should use the property access (ie, with self.) pretty much everywhere. I tend to fall into the latter camp, but I could accept arguments from the other side.

It's important to be reasonably consistent, though. And if you work with others it's good if you can have a team "standard" for this.

(One thing I like to do is to put the dealloc method at the top of the .m file, vs at the bottom where it usually ends up. This way you will be more likely to remember to update the dealloc method when you add/change a property and the associated @synthesize statement.)

‖放下 2024-12-14 19:11:19

在 dealloc 中使用“self.variable = nil”的一个问题是,如果您覆盖了“setVariable”,它可能会触发其他操作。例如,每当变量更改值时,某些类就会向委托发出信号,但一旦处于释放状态,您可能不想这样做。使用“[变量发布]”更安全一些。

希望 ARC 能够尽快让这一切消失。

The one problem with using "self.variable = nil" in dealloc is that it can trigger additional actions if you have overridden "setVariable". For example, some classes will signal a delegate whenever a variable changes values but you probably don't want to do that once you are in dealloc. It's a bit safer to use "[variable release]".

Hopefully ARC will make all of this go away soon.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文