macOS Objective-C: use a pointer, or use return?

[Sandy Santra]

I'm a slightly confused newbie learning basic Objective-C from BecomeAnXcoder, and I'm wondering: when do you use "return" to return the result of a function call, and when (instead) do you use pointers? These are two different ways of handling scope limitations, as far as I can see, but I don't understand when/why to use each.

Thanks in advance for your thoughts, help, and explanations.

 

[Cromulent]

I'm a slightly confused newbie learning basic Objective-C from BecomeAnXcoder, and I'm wondering: when do you use "return" to return the result of a function call, and when (instead) do you use pointers? These are two different ways of handling scope limitations, as far as I can see, but I don't understand when/why to use each.

Thanks in advance for your thoughts, help, and explanations.

You would use the return statement in both cases, except you would just return a pointer rather than say an int.

Unless I am misunderstanding the question. All a pointer does is point to an area of memory which contains some data.

 

[GorillaPaws]

Returns and pointers are not mutually exclusive.

 

[Sandy Santra]

Hmmm...

Well, the book first teaches about using return statements to pass the value back from the call after the function is executed.

Then 10 pages later it shows almost identical code for the function but without the return statement. It immediately thereafter says: "See! The function doesn't work! That's why you need to be using pointers! Now we'll talk about pointers, even though it's so advanced you may not get it."

And I don't. But it DOES totally make sense that they're not mutually exclusive.

What DOESN'T make sense is that they introduce the idea of pointers as if to advise: "The return statement is for children; what you really need are pointers!" (tm)

 

[lee1210]

You can only return one thing. It can be a structure, an object with lots of fields, an array of objects, etc. so there can be a lot of "stuff"... but it's still just one thing. If you need to modify many things, you can pass pointers to the method and have it modify them.

Otherwise... do you need to get something "new" from the method, or do you need to modify something that already exists? If the former, return, if the latter, pass the pointer to the thing.

-Lee

 

[lee1210]

Hmmm...

Well, the book first teaches about using return statements to pass the value back from the call after the function is executed.

Then 10 pages later it shows almost identical code for the function but without the return statement. It immediately thereafter says: "See! The function doesn't work! That's why you need to be using pointers! Now we'll talk about pointers, even though it's so advanced you may not get it."

And I don't. But it DOES totally make sense that they're not mutually exclusive.

What DOESN'T make sense is that they introduce the idea of pointers as if to advise: "The return statement is for children; what you really need are pointers!" (tm)

They are trying to be funny/facetious. Returns always have a place. The biggest thing you could return is a complex structure, but normally you're returning a pointer or other primitive, in which case... those 8 bytes aren't hurting you that much. If you're at the point that you're building giant structures, you should know by then that passing a pointer around is a better idea.

-Lee

 

[Sandy Santra]

You would use the return statement in both cases

Actually, they don't:

void increment(int *y)
{
*y = *y + 1;
}

...

int myValue = 6;
increment(&myValue);

 

[Sandy Santra]

My impression is that the code can "return" something even when the "return" statement isn't used in the function, i.e.:

void increment(int *y)
{
*y = *y + 1;
}

If you just modify the value of a variable, it doesn't "stick" (globally), right? Whereas, if you use a pointer to modify the value, it seems that it does stick.

The book says:

"If you want to write a version of the increment function that actually works, i.e. accepts a variable as its argument and permanently increases the value of that variable, you need to pass it the address of a variable."

So they make it sound like you HAVE to use addresses to get anything done.

Whereas, I thought you could use a return statement (instead).

 

[kainjow]

In this case it can be done both ways, but often you write functions that accept a pointer to a struct and then the function modifies that struct.

So here is the same thing but using a return statement:

int increment(int y)
{
    return y + 1;
}

...

int myValue = 6;
myValue = increment(myValue);

By not using a pointer the value of myValue is copied, but you could change it to use the pointer instead.

 

[lee1210]

My impression is that the code can "return" something even when the "return" statement isn't used in the function, i.e.:

void increment(int *y)
{
*y = *y + 1;
}

If you just modify the value of a variable, it doesn't "stick" (globally), right? Whereas, if you use a pointer to modify the value, it seems that it does stick.

The book says:

"If you want to write a version of the increment function that actually works, i.e. accepts a variable as its argument and permanently increases the value of that variable, you need to pass it the address of a variable."

So they make it sound like you HAVE to use addresses to get anything done.

Whereas, I thought you could use a return statement (instead).

int increment(int y) {
  return y+1;
}
int main(int argc, char *argv[]) {
  int z = 1;
  z=increment(z);
}

There is always a way. The text your reading is just speaking more colloquially.

-Lee

EDIT: Kainjow beat me

 

[Sandy Santra]

In this case it can be done both ways, but often you write functions that accept a pointer to a struct and then the function modifies that struct.

So here is the same thing but using a return statement:

int increment(int y)
{
    return y + 1;
}

...

int myValue = 6;
myValue = increment(myValue);

By not using a pointer the value of myValue is copied, but you could change it to use the pointer instead.

OK, that is totally making sense.

Advantages/disadvantages of either method?

For instance is one method better for returning large structures? Or is one of these methods better for small, simple functions (or methods)?

 

[lee1210]

OK, that is totally making sense.

Advantages/disadvantages of either method?

For instance is one method better for returning large structures? Or is one of these methods better for small, simple functions (or methods)?

Better is relative. Is it easier for you to understand when something does a return? Then maybe that's better.

In absolute terms, it's cheaper to push a pointer onto the stack instead of a structure that's larger than the size of pointer on there. However, if you're writing objective-C, most things will be objects, not structures, so you'll always be passing a pointer no matter what.

For primitives, a pointer is about the same size (within a few bytes), so it's more a matter of style and need.

-Lee

 

[eddietr]

One style that is enabled by using 'return' is "chaining" of function calls or method calls together.

So for example:

[[[NSObject alloc] init] autorelease]

would not be possible if 'alloc' and 'init' didn't return the id of the object. BTW, 'id' is a pointer.

 

[Sandy Santra]

Thanks, all, for everyone's great answers. Huge help.

Still getting my feet wet, so some of this is over my head, but it's all helpful, and also very interesting and exciting.