Question

I have a question.

I first created an object which extends NSObject, I provided overrides for the description and dealloc methods. Here’s my Employee.m file:

@implementation Employee
.....

-(NSString *)description
{
    return [NSString stringWithFormat:@"Employ ID: %d has $%d value of assets", [self     employeeID], [self valueOfAssets]];
}

-(void)dealloc
{   
    NSLog(@"deallocating.. %@", self);
    [super dealloc];
}

In my main.m, I first created an NSMutableArray to hold a list of Employee objects:

NSMutableArray *employees = [[NSMutableArray alloc] init];

for (int i =0; i< 10; i++)
{
    // Create an instance of Employee
    Employee *person = [[Employee alloc] init];

    // Give the instance varaible interesting values
    [person setEmployeeID:i];
    [employees addObject: person];
}

and at the end I set employees to nil

employees = nil;

I expected the dealloc method of each Employee object to be called and I would see some logs like:

deallocating.. Employ ID 0 has value.....
deallocating.. Employ ID 2 has value.....
....

However, I didn’t see any logs and if I set a breakpoint on the dealloc method, the breakpoint is never hit.

Any thoughts?

Answer 1

A couple of observations:

1. person = nil does not release an object in non-ARC code. It will in ARC code (at least if it’s strong).

2. In ARC, local objects will be released for you automatically when they fall out of scope. In non-ARC, objects falling out of scope will not be released for you (and if you don’t have other references to those objects elsewhere, you’ll end up with a leak).

3. Adding an item to a mutable array will increase the retain count of the item, so even if you include a release in your non-ARC code, the object won’t be released until the retain count drops to zero (accomplished by not only releasing the person objects after you add them to the array, but also removing them from the array.

Thus, given that this is non-ARC code, it could be something like:

- (void)testInNonArcCode
{
    NSMutableArray *employees = [[NSMutableArray alloc] init]; // employees retain count = +1

    for (int i =0; i< 10; i++)
    {
        //create an instance of Employee
        Employee *person = [[Employee alloc] init]; // person retain count = +1

        //Give the instance varaible interesting values
        [person setEmployeeID:i];
        [employees addObject: person];  // person retain count = +2
        [person release];  // person retain count = +1 (YOU REALLY WANT TO DO THIS OR ELSE OR NON-ARC PROGRAM WILL LEAK)
        // person = nil;   // this does nothing, except clears the local var that's limited to the for loop scope ... it does nothing to reduce the retain count or improve memory management in non-ARC code, thus I have commented it out
    }

    // do whatever you want

    [employees removeAllObjects]; // this will remove all of the person objects and they will have their respective retain counts reduced to 0, and therefore the Employee objects will be released

    [employees release]; // employees array's own retain count reduced to zero (and will now be dealloced, itself)
}

In ARC code:

- (void)testInArcCode
{
    NSMutableArray *employees = [[NSMutableArray alloc] init]; // employees retain count = +1

    for (int i =0; i< 10; i++)
    {
        //create an instance of Employee
        Employee *person = [[Employee alloc] init]; // person retain count = +1

        //Give the instance varaible interesting values
        [person setEmployeeID:i];
        [employees addObject: person];  // person retain count = +2

        // person = nil;      // this would reduce person retain count to +1 (but unnecessary in ARC because when person falls out of scope, it will have it's retain count automatically reduced)
    }

    // do whatever you want

    [employees removeAllObjects]; // this will remove all of the person objects and they will have their respective retain counts reduced to 0, and therefore will be released

    // [employees release]; // not permitted in ARC
    // employees = nil;     // this would effectively release employees, but again, not needed, because when it falls out of scope, it will be released anyway
}