Objective C: Returning Objects from Methods

I'm learning how to program, and starting off with Objective C. I'm trying to understand exactly what happens when an object is allocated from within a method.

-(Fraction *) add: (Fraction *) f
{   //'result' will store the result of the addition

Fraction *result = [[Fraction alloc]init];

result.numerator = (numerator*f.denominator + denominator*f.numerator);
result.denominator = denominator*f.denominator;

[result reduce];
return result;
}

I understand that I can create an object to store 'result' in when it is returned,

tempStorageObject = [aFraction add: bFraction];

and that i am then responsible for releasing it, but what happens when I don't store it, as in:

[aFraction add: bFraction];
NSLog(@"%i/%i", result.numerator, result.denominator); //result object not declared in main
开发者_运维知识库

I am told that I have an undeclared identifier. I get that, but what exactly happens to 'result' after using my 'add' method. Where does it go? Shouldn't I be able to access its variables since it was created and returned in the method? Obviously not, but I'm not clear on why. I've tried re-reading my book and searching this forum but I can't find a clear answer. Thanks. (First post)

Four different things:

1. Properties
2. Local variables
3. Function return values
4. Heap storage

"I get that, but what exactly happens to 'result' after using my 'add' method. Where does it go?"

It's a local variable. It's gone.

"Shouldn't I be able to access its variables"

Seeing your comment, it looks like you mean access by dot notation. No, dot notation is for properties.

"since it was created"

Dot notation does not give you access to local variables.

"and returned in the method?"

Dot notation does not give you access to function return values.

All of the first three things are pointers, when they refer to objects. The fourth thing is what they point to. When you do alloc, you create an object in heap storage. You then have instance variables, properties, local variables, and function return values refer to the heap storage. In a way you think of them as being the same thing as the object in heap storage. Syntactic sugar like dot notation helps you do that. Your object will last, but in this case the different variables that refer to it are limited in scope and come and go.

1. When you call alloc, an object is created on the heap.

2. When you assign it to result, result now has the same object.

3. When you return result, the local variable result no longer exists, the return value temporarily holds the same object, and the object still exists in the heap.

4a. When you assign the function result to tempStorageObject, another local variable (I guess), the function result goes away. It existed only temporarily to pass a value from inside the function to out. tempStorageObject now holds the object, and the object still exists in the heap.

4b. Instead if you don't assign the function result to anything, then the function result still goes away. But the object still exists on the heap. You have a problem. You have an object on the heap, but you can't refer to it directly there (unless you are good at guessing its address). Without being able to refer to it, you can't get it off the heap, which will be a major problem if you do that kind of thing over and over. The heap will start to get full with objects you can't get rid of and you'll run out of memory. That's what's called a leak.

The correct thing to do in this case is to return [result autorelease]. When you call [something autorelease], it adds "something" to an "autorelease pool" and then returns the same something.

1. You call alloc and create an object on the heap. Its retain count starts at 1.

2. You assign it to result, a local variable. Result has the object and it's on the heap.

3. [result autorelease]. result has the object, it's in an autorelease pool, and it's on the heap.

4. return that. result is gone, the return value has the object, it's in the autorelease pool, and it's on the heap.

5a. Assign the return value to tempStorageObject. The return value is gone, tempStorageObject has the object, it's in an autorelease pool, and it's on the heap.

6a. You leave the scope of tempStorageObject. tempStorage object is gone. The object is in an autorelease pool and on the heap.

5b. You don't assign the function result to anything. The function result is gone. The object is in an autorelease pool and on the heap.

7ab. The autorelease pool is drained. That is usually done from code in the main run loop provided by the system library, but you can do it yourself if you know how. All the objects in the autorelease pool, including the one we're paying attention to, are sent a release message. The object's retain count goes to 0.

8ab. With a retain count of 0, the object is removed from the heap. The object is in the autorelease pool.

9ab. The second thing drain does is remove all the objects from the pool. Now the object doesn't exist anywhere anymore.

You said you are familiar with release, so I just say you should use autorelease keyword, which releases the allocated object when no more code blocks need it, check document below, from Apple:

Memory Management Programming

The scope of alloc is global: once you have allocated an object, there is room for it in memory and that memory will remain allocated until the release count hits zero (or the app is terminated). Until then, the object will still exist.

The scope of a variable is much shorter. In your example 'result' goes out of scope right at the end of the method 'add'. But that variable is just a name, a reference to an object. So whoever is calling add, should make sure to do something with the returned object. Otherwise there is no more variable referring to the object and so it can not be released.