return value of functions

assume this little code

Code:

---

SomeObject my_func()
{
  return SomeObject(...); // 1
}


void some_other_function()
{
  SomeObject so = my_func();
}

---

what happens to the return value on return?
so where does it exist? is it appended to top of stack of the calling function?
or does it exist outside the stack frame of the caller (thus in the stack-frame of the callee which no longer exists then)?
and how long is that return value valid - so when is the destructor of it called?

immediately after the next operation (e.g. i _+_ func()) (in case there is one (e.g. func(); )?



and how is that value returned? it seems that integers and floats are returned directly through a register.
but what about objects? is the address of the returned object put into a register then?

so does anyone know where to find an explanation (or could explain) of how functions return their value - and how long it stays valid (thus when is it destroyed), and how often and when it is constructed/destroyed during that process?

return doesnt exist after return

verify via reference

Kuphryn

When you call a function, a stack frame is established. This stack frame is a queue data structure made out of memory locations, and is built in the following way:

1. The return address is put onto the stack. This is the address that the function will return to after it completes execution, it is also the address that contains the return type:
2. On top of that is room for the return type.
3. Then your function's arguments are placed on the stack.
4. From here, the program branches out to your function and local variables are placed on the stack as they are defined.

When your function returns, the reverse happens as the stack is destroyed, and you end up with the return variable being located on the caller's stack frame. Since the caller has not returned yet, this memory is still available to you.

You must be careful that you do not return a pointer or a reference to stack memory. That is dangerous and results in the pointer or reference pointing to garbage.

It resides in the free-store. At least that's the interpretation I make from Strousptrup's 3rd Edition.

When a function is called, store is set aside for its formal arguments (non reference and non pointer ones) and, I'm assuming, the return object (when this is not a reference or pointer). A return statement initializes an unnamed variable of the same type as that of the returned type. Type checking and conversions are done and the variable is then copied to the caller object. Next the store is reused, and thus the temp destroyed.

Since non dynamically allocated objects are the only ones residing on the stack, I reckon the temporaries (arguments and return objects) are created on the free-store.

EDIT: Ah! Citizen seems to have nailed it. Ignore my reply.

There are two possible outcomes. The first is that a temporary SomeObject is created inside the function, and then passed to the copy constructor to create a second SomeObject instance "so". The temporary object inside the function is destructed after so is created.

A second possibility is that the compiler will utilize return value optimization. In that case, instead of constructing a temporary SomeObject, it will construct "so" with the parameters specified in the function's return statement. It can do this since it is obvious that the temporary will only be used to constructo "so" and then go out of scope.

The second possibility is probably more likely in the posted case.

In the general case of a function that returns by value, the object returned goes out of scope after it is used as the return value.

I'm not sure I follow the citizen's answer above completely, but I don't think it is correct. The object created inside the function is destroyed. As (apparently) kuphryn was trying to say, if you make "so" a reference variable, it will be referring to the temporary object returned from the function, which will be destroyed by the time you try to use "so".

so what happens to the return type is, that simply the storage is allocated on the stack, but left uninitialized

thus:

Code:

---

SomeObject func(arg0 -  argn) { ... }

---

internally translates to something similar

Code:

---

void func(arg0 - argn,  "sizeof(SomeObject) bytes") { ... }

---

(so the last parameter is the one deepest in the stack - thus when the callee returns, the return value is the "top-of-stack" of the caller.

so the layout would be:
[ stack frame of the caller ] [ return value of the callee ] [return address] [ arg n ] ... [ arg 0] [ local variables of the callee]

uh, wouldn't it make more sense pushing the return address AFTER the storage for the return type? since then everything can be cleaned up, leaving just the return value alone on top of the stack.

or is the correct order really ... [return address] [return value of the callee] ?
well in that case the extra few bytes of the return address need to be cleaned up too - not that this is a problem, but the other solution looks better - or are there problems with it?

Are you trying to write a compiler?

Both your ideas are equally plausable, it all depends on how the compiler writer has chosen to implement it.

All that matters to you is that the result appears as an r-value which can be assigned to an l-value of the same (or compatible) type.
Like so
SomeObject so = my_func();

If you're that keen to know, then I suggest looking at the asm output, with say
gcc -S foo.cpp
for objects of varying sizes.

>> Are you trying to write a compiler?

hehe, yes... once again - maybe this time i might even finish it :)
well i'll implement the ordering [return value] [return adress], which just leaves the return value alone on the stack then.

thxalot