Amazon.com Widgets Program 7.5 - 7.6 stuck
Welcome, Guest. Please login or register.
Did you miss your activation email?
September 30, 2014, 03:09:47 AM
Home Help Search chat Login Register 
News: Read this please.The Great Kangaroo Escape Looking for reviews of the 4th ed on Amazon!   Twitter:  @skochan
                     

+ Official Forum for Programming in Objective-C (the iPhone Programming Language) - Stephen Kochan
|-+ Old Stuff
| |-+ Chapter Study
| | |-+ Chapter 7 - More on Classes
| | | |-+ Program 7.5 - 7.6 stuck
Pages: 1 ... 5 6 [7] Go Down
Print
Author Topic: Program 7.5 - 7.6 stuck (Read 23708 times)
gerhard
Newbie
*
Posts: 8


Email




Reply #90 on: August 08, 2011, 04:30:31 PM

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!

Cheers

Gerhard




Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #91 on: August 09, 2011, 09:50:45 AM

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).

Cheers,

Steve
Last Edit: August 09, 2011, 09:52:57 AM by skochan Logged
john67
Newbie
*
Posts: 32






Reply #92 on: August 09, 2011, 06:10:28 PM

Steve, congratulations for this awesome book and best of luck in the upcoming launch!

The Q&A of this topic is centered at "sum" and "sum2". But my question is regarding "result": shouldn't we release result at the end of the method?

Thanks and regards,
luis

Well yes and no: Yes because you do need to release it and No because the 'result' object is pointed to by 'sum2' and as sum = sum2, the 'result' object is released as 'sum' is released.
Logged
bpran
Newbie
*
Posts: 18






Reply #93 on: August 20, 2011, 07:22:29 AM

I am just making sure that I get this logic correctly.
Please give me some input if I make mistakes.


This is in the Fraction.m file
Code: (Objective-C)
-(Fraction *) add: (Fraction *) f
{
    Fraction *result = [[Fraction alloc] init];
   
    result.numerator = (numerator * f.denominator) + (denominator * f.numerator);
    result.denominator = denominator * f.denominator;
   
    [result reduce];
    return result;
}

and the other part is in the main.m
Code: (Objective-C)
    for (i = 1; i <= n; ++i) {  
         [aFraction setTo: 1 over: pow2]; 
         sum2 = [sum add: aFraction]; 
         [sum release]; 
         sum = sum2; 
         pow2 *= 2; 
    } 

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.
Logged
bpran
Newbie
*
Posts: 18






Reply #94 on: August 21, 2011, 09:01:12 PM

I really need someone to give comment on my post above.

Just want to make sure that I get the logic correctly, otherwise no point continuing reading thru.

Thank you.
Logged
Buko
Newbie
*
Posts: 4






Reply #95 on: December 29, 2011, 04:38:25 AM

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!

I hope this makes sense and is helpful to someone in the future.


SCN_0001 by Bukoth, on Flickr
Logged
Pages: 1 ... 5 6 [7] Go Up
Print
Jump to:



Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Entire forum contents (c) 2009 classroomM.com. All rights reserved.