Objective-C reference count when pointer set to nil (without ARC)

Question

I'm trying to understand how reference counting works, so I disabled ARC and wrote a simple class: (Foo.h is not pasted as it is unmodified)

Foo.m

@implementation Foo

- (instancetype)init
{
    NSLog(@"Init object");
    return [super init];
}

- (void)dealloc
{
    NSLog(@"Dealloc object");
    [super dealloc];
}

@end

Main.m

#import <Foundation/Foundation.h>
#import "Foo.h"

int main(int argc, const char * argv[]) {

    Foo *obj = [[Foo alloc] init];

    obj = nil;
    return 0;
}

Now I expect to see the dealloc object log, because the only reference to Foo object is gone, but the only message I get is the init object.

Why don't I see it? Isn't the object released when I assign obj = nil?

Answer 1

No. If you're not using ARC, the object is released when you call [obj release];. (ARC inserts these calls for you.) Setting obj to nil does nothing in terms of memory management (although it does create an object you can no longer reach!).

Basically, in Cocoa without ARC:

• You call [obj retain] if you want to take ownership of an object. (alloc does this for you.)
• You call [obj release] when you want to relinquish ownership of an object. release in turn calls dealloc when the object's retain count reaches 0.
• You call [obj autorelease] when you want to relinquish ownership of an object outside of its current scope. Most commonly, this happens when you return an object from a method (and don't want to retain ownership of it).

Answer 2

A couple of additional observations to expand on mipadi's excellent answer:

1. In non-ARC code, setting a variable to nil will not release the object. You must explicitly release/autorelease it.

   To be more precise about it, if ownership has been transferred to you (i.e. you obtain the object from a method whose name starts with either alloc, new, copy, or mutableCopy), then you're responsible for explicitly calling release/autorelease.

   Bottom line, simply setting the variable to nil is not adequate.

2. I hesitate to mention this for fear of clouding the issue, but when dealing with properties, it is a bit different. With properties, calling the setter of a retain property will automatically retain the object for you. If you later set the property to nil, then the setter will automatically release it for you.

   Imagine a class like so:

   @interface Bar : NSObject
   @property (nonatomic, retain) Foo *foo;
   @end
   

   When you want to set the foo property, you might do the following

   Foo *f = [[Foo alloc] init];  // create Foo object with +1 retain count
   self.foo = f;                 // the `retain` property will increase retain count to +2
   [f release];                  // resolve the local strong reference, reducing retain count back to +1
   

   Or, more simply:

   self.foo = [[[Foo alloc] init] autorelease];
   

   What these do is create a Foo object with a +1 retain count. By setting the foo property, you are creating another strong reference and thus ending up with a +2 retain count. And when you then release/autorelease it, the retain count falls back to +1.

   Later, when you're done with foo and want to release it, you would simply call the setter again, this time with nil value:

   self.foo = nil;              // resolve the `retain` done by the property, reducing the retain count to +0
   

   That relieves the strong reference that the foo property maintained to the object. You do not call release yourself (on the property, at least). Obviously, when you call the setter with a nil value, the previous object is not only released, but if that was the last strong reference, the object will be deallocated for you, too.

In short, the original alloc is offset by a release/autorelease, not by setting the variable to nil. However, the setting of a retain property is resolved by setting that property to nil.

---

A couple of final observations.

• I would suggest that if writing non-ARC code that you carefully review the Advanced Memory Management Programming Guide, particularly the Memory Management Policy chapter.

• Xcode's static analyzer (shift+command+B, or "Analyze" on Xcode's "Product" menu) is excellent at identifying memory issues that plague non-ARC code. Always make sure you have absolutely no warnings from the static analyzer.

• When using Instruments, the allocations tool has a feature called "Record Reference Counts" (see https://stackoverflow.com/a/14105056/1271826). If you're finding that some object is not getting released, this tool can be useful in diagnosing the full life cycle of the object and all of it's retain counts.