In some code I sometimes see this:
@property (nonatomic, assign) NSObject *foo;
...
-(void)dealloc
{
self.foo = nil;
...
}
Is it really necessary to nil an object when it hasn't been retained? Won't this actually cause problems?
In some code I sometimes see this:
@property (nonatomic, assign) NSObject *foo;
...
-(void)dealloc
{
self.foo = nil;
...
}
Is it really necessary to nil an object when it hasn't been retained? Won't this actually cause problems?
Assuming it's a synthesized accessor, there's no point to doing it in dealloc. Earlier, you might nil it out if you don't want to talk to the object anymore. I can't see how it would cause problems, though.
If it's not a synthesized accessor, the setter might also affect the inverse relationship in some way, and in that case it might be necessary to set it to nil in order to tell foo
you're not going to be around anymore.
A assign property does not have to have its ivar set to nil in -dealloc.
Setting the ivar to nil in -dealloc is harmless. Using the public accessor to set the property to nil in dealloc (either [self setFoo: nil] or self.foo = nil) may have unwanted side effects.
It is good practice to set any pointer you are no longer interested in to nil. I don't advocate the use of accessors like this in -dealloc
because of possible accessor side effects (like posting notifications or KVOs), but that's a controversial position and Apple is not consistent in their own code. In any case, it is good practice to nil your pointers. It certainly will not cause problems, and the habit of nil-ing your pointers in -dealloc
will save you significant bugs in the future.
In this specific case it may not be necessary, but what kind of problem are you suggesting?