When to make object nil and when to call release

2
votes

Today I see code in which user is releasing the object first and then he is making that object nil. like this

[objectA release];
objectA=nil;

I have read at many books that we should make the object nil while leaving the view and release the object later(in dealloc method of course this method is called after viewWillDisappear or viewDidDisappear).

Now i want to know that which approach is better?

6
iosobjective-ccocoa-touchmemory-management

6 Answers

6
votes

Setting to nil and releasing are two distinct operations.

You release an object to relinquish ownership of it. This is covered in the standard Memory Managemange Guidelines. If you are not familiar with them, you should read them before doing any further iOS programming.

After releasing an object, you should set it to nil if you know that some other code may attempt to access that variable later. This is most common with instance variables.

For example, you may use an instance variable to store some sort of cache:

- (NSArray *)items
{
    if (!cachedItems) {
        cachedItems = [[self calculateItems] retain];
    }

    return cachedItems;
}

Later on you may need to clear this cache:

- (void)invalidateCache
{
    [cachedItems release];
    cachedItems = nil;
}

We need to set cachedItems to nil because our items method may attempt to use it later. If we do not set it to nil, messages send to the (now released) cache can lead to a crash.

So set a variable to nil after releasing it when it can potentially be access by other methods in your class at a later point in time.

2
votes

I don't think is important set object to nil, but is good to do.

If you do : 

  objectA = nil;
  [objectA release];

You have LOST the memory, and this is a memory leak. If you only do [objectA release], you will release the memory, but the objectA still point to the memory, so if you try to do things like: 

  if (objectA==nil)

This will return FALSE, because objectA is NOT a nil. But because you do this almost in 

  - (void)dealloc;

you don't need set it to nil in this function.

1
votes

If the object is created locally:

I would go with the first approach, it's a common practice to release the object first then assign an nil.

I haven'nt read about your second approach in any book.

If the object is the part of class variable and have retain and @synthesize :

The below will do the both work (first release then assign nil through setter function) at once.

self.object = nil ;
1
votes

First approach is the way to go for you..

[objectA release];
objectA=nil;

Also making object nil is a good practice (not if you are using it later) because after releasing the object, if I accidentally refers to it again your app will crash. But if you gave nil to the object, and you refer to it later it won't crash in objective C.(Situations similiar gave nullpointerException in languages like java)

ie

[objectA doneSomeTask];

wont crash,even if objectA is nil. As objective C silently ignores refering to nil.

0
votes

What you have read in books does not work. If you set the object to nil you can not release it later because you can not excess the object then. You should to the first approach.

0
votes

Best way:

[objectA release]; // sightly sightly faster since less function calls
objectA=nil;

Lazy way:

self.objectA=nil;

it will call:

(void)setObjectA:(ObjectAClass *)objectA
{
    [objectA release];         // <-- original value is released
    objectA = [objectA retain];// <-- set the point to nil and do nothing since nil
}