释放财产的可接受方式 [英] Acceptable ways to release a property

问题描述

假设有一个具有以下界面的类：

Assume there is a class with the following interface:

#import <Foundation/Foundation.h>

@interface MyClass : NSObject {

}
@property (nonatomic, retain) NSDate* myDate;

-(void)foo;

@end

以及以下实施：

#import "MyClass.h"


@implementation MyClass
@synthesize myDate = _myDate;

- (void)dealloc
{
    [_myDate release];
    [super dealloc];
}

-(void)foo
{
    NSDate* temp = [[NSDate alloc] init];
    self.myDate = temp;
    [temp release];
}

@end

1）在函数中 foo 会像这样释放，确保正确维护对象的保留计数（即没有内存泄漏且没有执行不必要的释放）。

1) In the function foo will releasing like this ensure that the retain count of the objects is properly maintained (i.e. no memory is leaked and no unnecessary releases are performed).

    NSDate* temp = [[NSDate alloc] init];
    self.myDate = temp;
    [temp release];

2）与1）相同的问题，除了适用于以下技术：

2) Same question as in 1) except applied to the following technique:

self.myDate = [[NSDate alloc] init];
[self.myDate release]

3）与1）相同的问题，除了适用于以下技术：

3) Same question as in 1) except applied to the following technique:

self.myDate = [[NSDate alloc] init] autorelease];

4）与1）相同的问题，但适用于以下技术：

4) Same question as 1) but applied to the following technique:

self.myDate = [[NSDate alloc] init];
[_myDate release]

5）与1）相同的问题但适用于以下技术：

5) Same question as 1) but applied to the following technique:

[_myDate release];
_myDate = [[NSDate alloc] init];

推荐答案

1）很好。

2）可能不安全，并会在最新的LLVM静态分析仪中触发警告。这是因为getter方法返回的对象可能与传递给setter的对象不同。 （例如，setter可能已制作副本，或者可能验证失败并设置了 nil 。这意味着您泄漏原始对象并过度释放吸气者给你的那个。

2) Possibly unsafe, and will trigger warnings in the latest LLVM static analyzer. This is because the object returned by the getter method may not be the same one you passed to the setter. (The setter may have made a copy, for example, or may have failed validation and set a nil instead.) This would mean you were leaking the original object and over-releasing the one the getter gave back to you.

3）很好;类似于1，但释放将在当前自动释放池被耗尽而不是立即释放。

3) Just fine; similar to 1 but the release will come when the current autorelease pool is drained instead of immediately.

4）可能不安全，但不会触发我见过的警告。问题类似于2中描述的问题; ivar中的对象可能不是你传递给setter的对象。

4) Possibly unsafe, but will not trigger warnings that I've seen. The issue is similar to the one described in 2; the object in the ivar may not be the one you passed to the setter.

5）安全，但不会使用setter方法或通知任何观察者的属性。

5) Safe, but will not use the setter method or notify any observers of the property.

如果属性是 retain 类型，则getter和setter都只是合成版本，以上所有例子都可行。但是，它们并不都代表最佳实践，并且可能触发分析警告。目标应该是 -foo 方法正常无论如何 myDate 正在管理它的记忆。您上面的一些示例不会这样做。

In the case where the property is a retain type, and both the getter and setter are just the synthesized versions, all of the above examples will work. However, they don't all represent best practice, and may trigger analysis warnings. The goal should be that the -foo method works correctly regardless of how myDate is managing its memory. Some of your examples above don't do that.

例如，如果您决定将属性更改为 copy 稍后，不应要求您更改任何其他代码以使其正常工作。在情况2和4中，将需要更改其他代码，因为 foo 方法假设setter将始终成功并始终设置原始对象。

If, for example, you decided to change the property to copy later, you should not be required to change any other code to make it work correctly. In cases 2 and 4, you would be required to change additional code because the foo method is assuming that the setter will always succeed and always set the original object.

这篇关于释放财产的可接受方式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！