Assume there is a class with the following interface:
#import <Foundation/Foundation.h>
@interface MyClass : NSObject {
}
@property (nonatomic, retain) NSDate* myDate;
-(void)foo;
@end
and the following implementation:
#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) 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) Same question as in 1) except applied to the following technique:
self.myDate = [[NSDate alloc] init];
[self.myDate release]
3) Same question as in 1) except applied to the following technique:
self.myDate = [[NSDate alloc] init] autorelease];
4) Same question as 1) but applied to the following technique:
self.myDate = [[NSDate alloc] init];
[_myDate release]
5) Same question as 1) but applied to the following technique:
[_myDate release];
_myDate = [[NSDate alloc] init];
1) Just fine.
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
nilinstead.) This would mean you were leaking the original object and over-releasing the one the getter gave back to you.3) Just fine; similar to 1 but the release will come when the current autorelease pool is drained instead of immediately.
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) Safe, but will not use the setter method or notify any observers of the property.
In the case where the property is a
retaintype, 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-foomethod works correctly regardless of howmyDateis managing its memory. Some of your examples above don’t do that.If, for example, you decided to change the property to
copylater, 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 thefoomethod is assuming that the setter will always succeed and always set the original object.