views:

51

answers:

2

Hello,

since every assignment to a variable with a different object increases its retain count and in the dealloc its not always clear how often a variable got assigned a simple [maVar release] might NOT BE SUFFICIENT. So using ALWAYS myVar = nil sets the retain count to zero, and a subsequent [myVar release] will never cause a problem again. (is it actually still required ?)

The only situation when not to do it this way is if myVar is passed OUT then I must not do this, since the value gets destroyed by myVar = nil;

Is my thinking correct? Or could this way of avoiding leaks cause any other problems?

Thanks!

+1  A: 

Please read Apple's documentation on Memory Management.

Assigning a pointer to an object will not increment the retain count, only calling retain does that. Functions with Copy or Init in the name should return an object with a retain count of 1, other functions should return autoreleased objects that will be dealloc'd when the main loop finishes.

Setting an object to nil doesn't modify the retain count, but it will cause that memory to leak. Calling release on the pointer at that point essentially does nothing. You need to be responsible about using retain, release, autorelease, and how you name your functions if you want to effectively manage your memory usage.

Joe Ibanez
+3  A: 

Your thinking is incorrect in quite a lot of ways. These are probably just scratching the surface:

  • Assignment to a variable does not increase its retain count. (There are some subtleties to do with properties, but frankly that's way beyond the level we're at here.)
  • dealloc is called when the retain count reaches 0.
  • Setting myVar = nil does not affect the retain count.
  • myVar = nil destroys only the local pointer value, it does not destroy an object that has been passed out.
  • It is safe to call [myVar release] when myVar is nil, but it isn't useful -- it does nothing.
  • Worrying about retain counts is always a mistake. Worry about what you own.

It is clear that your grasp of C pointers and Objective-C memory management is a bit lacking. I'd suggest doing some remedial C work before several thorough re-reads of the Memory Management docs.

walkytalky
+1 technical correction: `dealloc` is called when you `release` an object with a retain count of 1. The retain count is technically never actually decremented to 0. However, for a general understanding of memory management, the "when it reaches 0" explanation is OK. :)
Dave DeLong
@Dave, thanks for the correction. I'd edit it in, but it might detract from the irascible tone ;)
walkytalky
@walkytalky that's fine. It was more of an "FYI" comment anyway. :)
Dave DeLong
Thanks for the clarification - The following test in XCode really confused me:I printed the [niVar retainCount] after each self.niVar = [NSNumber numberWithInt:11];=> The PRINTED RETAIN COUNT INCREASED AFTER EACH ASSIGNMENT.Then self.niVar = nil;=> The PRINTED RETAIN COUNT SHOWED 0.THAT'S ALL WRONG!!!!!What you clarified for me is that ONE SHOULD NOT PRINT THE RETAIN COUNT TO HELP FINDING POTENTIAL MEMORY PROBLEMS.So the only way to check is to go through the code thoroughly - difficult for beginners - since the LEAK instrument is rather limited in these cases.Thanks again!
@user387184 That's *exactly* the right conclusion to draw, well done. Just to explain what you saw: the increasing retain count was because you were looking at a *property*, presumably declared as `retain` and `@synthesized`. (`self.niVar` may look like a variable, but it isn't, it's a method call.) The reduction to 0 was because you were no longer looking at the object (which still existed somewhere with its big retain count), you were looking at `nil`, which always has a retain count of 0 because it's not an object at all. Anyway, remember your conclusion and you'll be much happier!
walkytalky
OK then! I hope this thread helps many others as it did for me. Even during the last 30 min or so I found many other discussions on this topic where others used [x retainCount] and most probably drew the wrong conclusions too.So I will re-re-re-read the documentation again and slowly get used to all this. Actually now I think it's much less complex than this stupid "retainCount" made it look like. SUPER!