Safe to return a local object?

[Tom]

I come from C but don't really understand why in C++ you can return a temporary object
from a function.
For example:

class Test {
public:

Test() { cout << "Address of object: " <<this <<endl; }
~Test() { }
};

Test func() {
Test tmp;
cout << "func(): Address of tmp: " << &tmp <<endl;
return tmp;
}

int main() {

Test a = func();
cout <<"main(): Address of a: " <<&a <<endl;
}


Output:
func(): Address of tmp: 0x22ff30
main(): Address of a: 0x22ff30


The output shows the same address on the stack for the two objects, but the same code in C
using structures instead of classes shows a different address ("tmp" local to the func stack
and "a" local to main).

So I have some questions:

Aren't local variables (and objects) created in the stack?
If so, why the local object is not destroyed after the function call?
Shouldn't they point to different addresses, with a local copy for each one?


Thanks for any clearing of confusion you can contribute...

 

[Phlip]

Test a = func();
cout <<"main(): Address of a: " <<&a <<endl;

Output:
func(): Address of tmp: 0x22ff30
main(): Address of a: 0x22ff30

The compiler had the option to create two objects, and call a copy
constructor.

However, you wrote a detector for the "return value optimization". Google
for that. It essentially means the compiler is free to secretly pass a
_into_ func(), to construct it in that context, and to skip the copy
construction at return time.

The Standard defines this optimization because without it, the compiler
would not know how to optimize this situation, because a programmer might
depend on a side-effect of the copy constructor. Without the RVO rule, if
the compiler aggressively optimized this code, the side-effect would
disappear and the code would break.

With this rule, developers are instructed not to rely on side-effects, such
as the one you discovered. And the compiler can optimize better. Without
this rule, we would be forced to write ugly code that avoided the extra
constructor and copy operation. So the rule permits cleaner code.

 

[Victor Bazarov]

I come from C but don't really understand why in C++ you can return a
temporary object
from a function.

There is this magical place where temporary objects are born and live their
wonderous lives. C doesn't have it.

For example:

class Test {
public:

Test() { cout << "Address of object: " <<this <<endl; }
~Test() { }
};

Test func() {
Test tmp;
cout << "func(): Address of tmp: " << &tmp <<endl;
return tmp;
}

int main() {

Test a = func();
cout <<"main(): Address of a: " <<&a <<endl;
}


Output:
func(): Address of tmp: 0x22ff30
main(): Address of a: 0x22ff30

There seems some output missing...

The output shows the same address on the stack for the two objects,
but the same code in C using structures instead of classes shows a
different address ("tmp" local to the func stack and "a" local to
main).

So I have some questions:

Aren't local variables (and objects) created in the stack?

That's what some believe. The Standard doesn't say where local objects
are created.

If so, why the local object is not destroyed after the function call?

The compiler could be optimizing all the copying away.

Shouldn't they point to different addresses, with a local copy for
each one?

They don't have to. The compiler can optimize creation of any objects
it pleases. Even if the constructors have side effects.

V

 

[rashmirishikesh]

Local variables are destroyed at the time of return but in c++ copy
contructor creates a copy of that object, just write ur own copy
contructor in this program like
Test(Test& a)
{
cout<<"Copy constructor ::";
cout<<this<<endl;
}
and you will see two different objects got created, write one cout in
ur destructor and you will see that before the function was returned
the copy contrutor was called to make a new copy of the object and then
temporary object was destroyed.

 

[Phlip]

Local variables are destroyed at the time of return but in c++ copy
contructor creates a copy of that object, just write ur own copy
contructor in this program like
Test(Test& a)
{
cout<<"Copy constructor ::";
cout<<this<<endl;
}
and you will see two different objects got created, write one cout in
ur destructor and you will see that before the function was returned
the copy contrutor was called to make a new copy of the object and then
temporary object was destroyed.

That's another example of a side-effect that might disappear with RVO.