Thread: How does returning values from functions work?

Hello!

I am learning to use functions in C++. Specifically, I have questions about using the keyword "return" inside function body. I hope someone can help me understand this.

Program 1:

Code:

#include <iostream>

using namespace std;

int myFunc(int a, int b)
{
    int sum;
    sum = a+b;
}

int main()
{
    cout << myFunc(1, 3);

    return 0;
}

Program 2:

Code:

#include <iostream>

using namespace std;

int myFunc(int a, int b)
{
    int sum;
    sum = a+b;
    return sum;
}

int main()
{
    cout << myFunc(1, 3);

    return 0;
}

Program 3:

Code:

#include <iostream>

using namespace std;

int myFunc(int a, int b)
{
    int sum;
    sum = a+b;
    return sum;
    return a;
    return b;
}

int main()
{
    cout << myFunc(1, 3);

    return 0;
}

Program 4:

Code:

#include <iostream>

using namespace std;

int myFunc(int a, int b)
{
    int sum;
    sum = a+b;
    return a;
}

int main()
{
    cout << myFunc(1, 3);

    return 0;
}

Question 1:
What's the difference between Program 1 and Program 2? I don't understand. Why is Program 1 returning 4 when I didn't ask it to? (Or did I?...)

Question 2:
How did Program 1 know to return 4 and not 1 or 3?

Question 3:
Why does Program 3 not return 4, 1, and 3? It can only return one number at a time? And since statement to return sum comes first, it just returns it and steps out of the function?

Question 4:
The return type is int because of the "int" in front of myFunc()? Is this causing the function to return a value (int) even when I don't ask it to do so (when not using the return keyword)?

I can try to answer Question 3:

It does seem like it can only return one number at a time, and order in which they appear does make a difference.

Porgram 5:

Code:

#include <iostream>

using namespace std;

int myFunc(int a, int b)
{
    int sum;
    sum = a+b;
    return b;
    return a;
    return sum;

}

int main()
{
    cout << myFunc(1, 3);

    return 0;
}

This program returns 3, because "return b" is at the top of other return statements.

Now that I think about it, functions can only have one single output. But they can have one or more inputs. Is that right?

So this function then takes two inputs, and produces one output. It produces an output as soon as I call it and give it two inputs? Regardless of if I ask it to return or not? I mean it's like auto returning at the moment I call it?

Program 6:

Code:

#include <iostream>

using namespace std;

void myFunc(int a, int b)
{
    int sum;
    sum = a+b;
    return sum;
}

int main()
{
    cout << myFunc(1, 3);

    return 0;
}

When I change the int to void I get an error. Two actually, one for the return statement and one for the output stream.

Code:

error: return-statement with a value, in function returning 'void' [-fpermissive]

error: no match for 'operator<<' (operand types are 'std::ostream {aka std::basic_ostream<char>}' and 'void')

This seems to support my view. But I still don't know how it knows what to return without me specifying it. I mean how it knows to return 4 and not 1 or 3.

Question 1:
What's the difference between Program 1 and Program 2? I don't understand. Why is Program 1 returning 4 when I didn't ask it to? (Or did I?...)

Program 1 is in error, so it's not an alternative to Program 2, which is correct. The function returning the value 4 might be undefined behavior, which is a complex topic you needn't worry about yet. If your function doesn't have a void return type, you must always return a suitable value.

Question 2:
How did Program 1 know to return 4 and not 1 or 3?

See answer above.

Question 3:
Why does Program 3 not return 4, 1, and 3? It can only return one number at a time? And since statement to return sum comes first, it just returns it and steps out of the function?

Yes, the first return statement encountered will "return from the function", i.e. statements following it within the function body will not be executed. It's as simple as that. If you need to return multiple values, they could be contained in a structure, but that's a topic for later.

Question 4:
The return type is int because of the "int" in front of myFunc()? Is this causing the function to return a value (int) even when I don't ask it to do so (when not using the return keyword)?

Yes, the int before it specifies what it can return. Since Program 1 is in error, the scenario you lay out shouldn't concern you, it's a mistake to not return some value from a non-void function.

Originally Posted by cozySam

I can even get the number 1 printed on screen without writing anything inside function body. This must be a problem with the compiler as well.

Turn on warnings in your compiler or IDE, and it will warn you about several things, such as failing to return a value from a function when you should have. You always have the opiton to ignore the warning and run the code anyway, but the result will be unpredictable.

Originally Posted by Guest

You got it. By the way: in C++, main is the one function that returns implicitly, so you don't need the return 0; at the end – that's taken care of.

Yeah, I heard Bucky Roberts mention that in one of his videos. That's the new way since C++ 11 I think. I remembered that, so I was thinking if not my situation with return statement had anything to do with that. Now I know for sure, it only relates to the main(). Anyway, thanks for helping me!

I heard Bucky Roberts mention

I'm not necessarily saying that what Bucky said in this or that instance is wrong, but... I would steer clear of his "tutorials". I'm not however denying that you can actually learn stuff in spite of them.

UB (unexpected behavior)

UB is undefined behavior. It's a specific term straight from ISO standards, and it's highly technical definition is: "Anything might happen, including a demon flying out of your nose and dancing macarena on your table." Don't believe the rumors though. We don't dance.

There's also that other definition that doesn't mention any demons and is - for some reason - preferred by the C++ standard committee. Here's a quote from N3797, C++14 working draft:

1.3.24 [defns.undefined]undefined behavior
behavior for which this International Standard imposes no requirements
[ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. — end note ]
1.3.25 [defns.unspecified]
unspecified behavior
behavior, for a well-formed program construct and correct data, that depends on the implementation
[ Note: The implementation is not required to document which behavior occurs. The range of possible behaviors is usually delineated by this International Standard. — end note ]

It's noteworthy to mention that some functions never return, by design. Think exit(), abort(), or... perpetually running function. You can even give them the special attribute [[noreturn]], like so:

Code:

[[ noreturn ]] void f() {
    throw "error"; // OK
}

(Notice that exiting a function by means of throwing an exception is not considered "returning".)
If such a function (with [[ noreturn ]]) actually returns - macarena demons, you know the drill.
The attribute here is optional - you can have a function that never returns without it, and if at some point it actually returns - it's all well defined. It's just something that if you're learning C++ you might have never seen before - and might not see for quite some time to follow. I wouldn't worry about it none, but it won't hurt to know stuff like that is there.

It's actually not an error to have a function that never returns, even if it has a return type other than void. (Here's an exercise for ya! Think of an example of a function that never returns, but needs to have a return type other than void. I can think of one example. ) However:

6.6.3 The return statement [stmt.return]
2 [...] Flowing off the end of a constructor, a destructor, or a function with a cv void return type is equivalent to a return with no operand. Otherwise, flowing off the end of a function other than main (3.6.1) results in undefined behavior.

So you see, your first code sample - it's definitely UB.

As for inputs and outputs - technically, you have zero or more inputs and zero (when the return type is void) or one output . If it sounds so limiting when it comes to outputs that it's hard to believe it's true - well, that's because it's only technically true. You can only return one value from a function, with the caveat that that "value" can be a kind of a wrapper that actually holds more values, like an object of a class/structure. It's like a smartass with a large coat hiding his friends under it to pay less for the cinema ticket. He's "totes" a single value, dude. ; )

There's also another way to have more outputs - you can pass pointers into a function and access values that are "outside" by dereferencing them, or use references to do almost the same thing, turning some of your "inputs" into effective "outputs".

>>char* x = "Hello!";
If your book or tutorial is telling you this is OK, then you need to drop those books/tutorials and get a real book. First and foremost, you shouldn't be using C-style strings. You can probably google to find tons of good answers as to why not, so I'm going to avoid saying why.
But the reason I'm calling this out specifically is that the standard has deprecated conversion of const char* -> char* for string literals since... forever. Fast-forward a few years from now, that's not going to compile any longer. The standards committee has decided that this is illegal and so beginning with C++17, that's not going to compile.

Originally Posted by Xupicor

...There's also another way to have more outputs - you can pass pointers into a function and access values that are "outside" by dereferencing them...

Please! No pointers! Are we discussing C or C++ here?