I've learned that in dealloc
you do [object release];
but in viewDidUnload
(in a UIViewController subclass) you do self.object = nil
. What is really the difference because self.object = nil
(we're assuming object is a (nonatomic, retain)
property) retains nil
(which does nothing) and then releases the old value and then the reference count is 0 right?
4 Answers
self.object = nil
calls your setter, which will release the old value, set the member to nil
, and possibly do other things (it's a method, so it could do anything). The "anything" part of that is potentially dangerous; see this question, for example.
[object release]
releases the old value, but leaves the member as a now-dangling pointer, which is a good recipe for bugs. In dealloc
it doesn't really matter, since the pointer itself is about to go away too, but in any other case it's a very bad idea to release a member without setting it to nil
.
(As a sidenote, you should never assume that releasing an object gives it a reference count of 0. It releases your reference, but other objects may still have references to it.)
-
4Note also that Apple specifically recommends against using setters/getters in init and dealloc (for good reasons), hence the use of [object release] in dealloc - its not just "In dealloc it doesn't really matter", in dealloc it is the recommended way. – Peter N Lewis Jul 31 '09 at 08:31
-
Right, I meant that having a non-nil pointer doesn't really matter (as in, you don't need to then do object=nil after the release in dealloc) – smorgan Jul 31 '09 at 14:07
-
1Actually, with synthesized ivars, setters must be usd in dealloc. See http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/ObjectiveC/Articles/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW1 search for the phrase "synthesizing the instance variable". – ustun Oct 15 '09 at 17:36
-
@ustun, that's not necessarily true. You can use synthesized ivars and synthesize with a declaration like: @ synthesize myIvar = _myIvar; Then in dealloc, use [_myIvar release]; – tbehunin Oct 08 '11 at 15:08
-
3@ustun Note that `[myivar release]` is in fact _not_ using the setter. It's using the instance variable which backs `self.myivar`. So `[myivar release]` and `myivar = nil` are perfectly fine in dealloc. However `self.myivar = nil` is not. – memmons Feb 10 '12 at 18:43
If you do object = nil
without [object release]
, that might causes memory leaking. If you do [object release]
without object = nil
afterwards, object becomes dangling pointer as @Jim suggested. self.object = nil
is a sugar for setter function call.

- 8,501
- 5
- 42
- 81

- 731
- 7
- 8
If you do [object release], and want to access the object the app simply crash. If you do object = nil, and want to access the object nothing will perform.
The reason is in the [object release], you are attempted to free the object. so its dont have any pointer (no memoty).In the object = nil,
you are attempted to assign the object with null pointer. so if u trying to access the object nothing will happen.
Generally we wrote the code as [object release]; object = nil;
because if u access the object unexpectedly, the app wont crashed.

- 15,573
- 16
- 56
- 75

- 19
- 2
If you just release an object, then it will become freed object.
And if you try to perform any sort of operation on freed object then your app crashes. To avoid such accidents, it is always preferred "assign your object to nil after releasing it". Because we all know any operations performed on nil will not be executed :)

- 1,287
- 4
- 15
- 21