It's an imperfect analysis. It doesn't know that the object was allocated in the add: method.

Cheers,

Steve Kocnan

Hi, Steve

First of all, thank you for writing this great book!

I'm comfortable with the explanation that you and others have provided for the memory allocation in this example (7.6). However, it seems to me that the example does throw more curve balls than what your book's intention is. For instance, as was previously pointed out, the Analyzer doesn't approve either... As you can see in the attached image focussing on the 'add' method, the analyzer indeed complains that it violates the naming convention in the Memory Management Guide for Cocoa. It seems to me you've outwitted not only your readers, but also Apple! I guess CLEVER programming isn't always appreciated!

The analyzer is following standard naming conventions. However, those are "conventions" and not requirements. Later in the book you see how to use "autorelease" to handle this correctly and that satisfies the analyzer as well (see the note on page 142).

let's make example that 'i' in the main.m is 5, so the loop will be 5 times.

The 1st time, method 'add' will create object and put the reference to result and return the reference to sum2.And then the original sum is destroyed, after that the reference copy from sum2 into sum.

The 2nd time, the method 'add' will create NEW OBJECT at NEW MEMORY LOCATION and the reference store in the result and return the reference into sum2 which replace the previous reference sum2 had.The [sum release] will destroy the object that created by the method 'add' during the first loop (when i=1), after that sum will get the reference from sum2 (result also pointing at the same object here too).

The point here is the [sum release] from the i=1 and i=2 destroying different thing. One is destroying the object created by the setTo: over: method (the original sum) and the 2nd one is the object created by add method. Am I right here?

This process repeat until it fulfill the 'for' condition and then at the end of main.m we see another [sum release] which will destroy the object which sum, sum2, and result all pointing at the same thing.

Forgive my English, if my post is not clear please let me know, I will try to rephrase the wording.Thank you and please let me know all your comments.

Apologies for contributing to an old thread but this problem has taken me all day to figure out and I wanted to share my understanding of it. It was driving me nuts but I didn't want to skip it. I am really glad that I didn't as it has corrected some wrong assumptions that I had made in my head. It has taken me going through the code over and over and reading all the relevant threads but in the end drawing some diagrams with pen and paper in conjunction (which I always find very helpful) is what solved the mystery for me. At least, I think I have got it right. Any feedback if anyone is still around would be cool.

My main mistake was to think of the variables as the objects themselves rather than pointers that pointed to memory locations where the objects exist. This is why I found the

[sum release];

line in mid-loop really confusing. It didn't make sense to me that you could release it and then immediately on the next line use it again. I now understand that the memory location was released but the pointer is left free to point at elsewhere on the next line.

It was taking too long to draw the diagrams in ASCII so I have included my hand drawn page below.

If the memory locations weren't released in the loop but sum was made to point to the new sum then all those shaded boxes below would add up and all those memory locations would still be in use with no way to release them because the pointer to them would have moved on hence the memory leak. If the for loop was a long one consisting of hundreds or more iterations then that's a lot of shaded boxes being wasted!