Copy constructor at return

[Igor.Smirnov]

Hi,

Why g++ in Linux does not call copy constructor at return statement?

I have detected this at Sicentific Linux 4.1 (g++ v. 3.4.3) and Red Hat
Linux 8.0 (g++ v. 3.2).

Microsoft Visual Studio C++ v. 8 at Windows XP calls them as necessary
(as should be according to Stroustrup and my previous experiense),
that is it calls the copy constructor for the object, returned by
"return".

To the contrary, in Linux the copy constructor is NOT called.
How this may happen? The local automatic object should be desrtoyed. How
its content is transferred to outside scope without either constructors,
or assignment operators (they are also not colled, as the code below
shows)?

To illustrate this consider the following simple program and its output
at both Linuxes and at Windows (which is different), see below.

Who knows the explanation of this behaviour of g++, please help me to
understand this!

Thanks
Igor

------------------------------------------------------

#include <iostream>
using std::cout;
using std:stream;


class X
{
public:
int i; // just anything
X(int fi) {i = fi;}
X( X& fx)
{
cout<<"X::X(X& fx) is called\n";
*this = fx;
}
X(const X& fx)
{
cout<<"X::X(const X& fx) is called\n";
*this = fx;
}
X& operator=(const X& fx)
{
cout<<"X:perator=(const X& fx) is called\n";
if(this != &fx) i = fx.i; return *this;
}
void print(ostream& file)
{
file<<"X:rint(): i = "<<i<<'\n';
}
};

X func(int fi)
{
// create local instance of X
X x(fi);
cout<<"func:\n";
x.print(cout);
cout<<"calling return\n";
return x;
}

int main(void)
{
X ex1(0);
cout<<"Calling func\n";
ex1 = func(1);
cout<<"func is finished\n";
ex1.print(cout);
cout<<"Calling func second time\n";
X ex2( func(2) );
cout<<"func is finished\n";
ex2.print(cout);
cout<<"Calling func third time\n";
X ex3 = func(3);
cout<<"func is finished\n";
ex3.print(cout);
}

----------------------------------------

Output at Linux & and Windows Parts which appear only at Windows:
(with empty lines added)

Calling func
func:
X:rint(): i = 1
calling return
X::X(X& fx) is called
X:perator=(const X& fx) is called
X:perator=(const X& fx) is called
func is finished
X:rint(): i = 1
Calling func second time
func:
X:rint(): i = 2
calling return
X::X(X& fx) is called
X:perator=(const X& fx) is called
func is finished
X:rint(): i = 2
Calling func third time
func:
X:rint(): i = 3
calling return
X::X(X& fx) is called
X:perator=(const X& fx) is called
func is finished
X:rint(): i = 3


--

 

[Heinz Ozwirk]

Hi,

Why g++ in Linux does not call copy constructor at return statement?

I have detected this at Sicentific Linux 4.1 (g++ v. 3.4.3) and Red Hat
Linux 8.0 (g++ v. 3.2).

Microsoft Visual Studio C++ v. 8 at Windows XP calls them as necessary
(as should be according to Stroustrup and my previous experiense),
that is it calls the copy constructor for the object, returned by
"return". ....
X func(int fi)
{
// create local instance of X
X x(fi);
cout<<"func:\n";
x.print(cout);
cout<<"calling return\n";
return x;
}

The compiler is allowed to optimize the code to eliminate such temporary
objects if the local variable exists as long as a temporary object created
for the return statement would exist. Search for "return value optimization"
for more details. If you'd add messages to your destructor, you would
probably see that the local variable is only destroyed after the assignment
operator in the calling code has been called.

HTH
Heinz

 

[Bart]

The compiler is allowed to optimize the code to eliminate such temporary
objects if the local variable exists as long as a temporary object created
for the return statement would exist.

Only if there are no side effects. Calls to library functions are side
effects.

Regards,
Bart.

 

[Kai-Uwe Bux]

Only if there are no side effects. Calls to library functions are side
effects.

Sometimes, and in particular in return value optimization, the compiler is
allowed to eliminate side effects. From the standard [12.8/15]:

When certain criteria are met, an implementation is allowed to omit the
copy construction of a class object, even if the copy constructor and/or
destructor for the object have side effects. In such cases, the
implementation treats the source and target of the omitted copy operation
as simply two different ways of referring to the same object, and the
destruction of that object occurs at the later of the times when the two
objects would have been destroyed without the optimization. This
elision of copy operations is permitted in the following circumstances
(which may be combined to eliminate multiple copies):

? in a return statement in a function with a class return type, when the
expression is the name of a non-volatile automatic object with the same
cv-unqualified type as the function return type, the copy operation can
be omitted by constructing the automatic object directly into the
function?s return value

? when a temporary class object that has not been bound to a reference
(12.2) would be copied to a class object with the same cv-unqualified
type, the copy operation can be omitted by constructing the temporary
object directly into the target of the omitted copy


Best

Kai-Uwe Bux