C++ compiler "return" behavior (guru question ;)

[Axel Bock]

Hi all,

I am trying to get my head around what happens if I return a class
object from a function.
It seems C++ (MinGW) does not invoke the copy constructor if I do
something like this:

SomeObj foo()
{
SomeObj X;
// ....
return X;
}

BUT it does create a new object every time the function is invoked, and
it does seem like these objects are usable (I created a little test
program checking this :).
So basically I can go in main:

int main()
{
// ....
SomeObj bar = foo();
SomeObj bar2 = foo();
// for some strange reason the next thing will fail, though:
SomeObj &bar3 = foo();
}

and I will get two different objects back, both valid. (As commented,
the third will fail with some obscure warning about temporary objects -
but there's no copying taking place, so there's no temp object, AFAIK).
Hm.

So I checked something else:

void foobar()
{
SomeObj IamUseless;
}

That object is actually constructed, but destroyed after the function.
Now I am a bit unsure how the C++ compiler can determine EACH TIME
which object gets returned (maybe in the depth of an STL container of
whatever), and which one does NOT, so this has to be destroyed.

Usually I use new() for factories, but I wondered, and I checked. And I
don't get it :) . So maybe there's a guru in here who can help me out
with some background information? ;)
Cheers & thanks,
Axel.

[Ian Collins]

Axel Bock wrote:

Hi all,

I am trying to get my head around what happens if I return a class
object from a function.
It seems C++ (MinGW) does not invoke the copy constructor if I do
something like this:

SomeObj foo()
{
SomeObj X;
// ....
return X;
}
The compiler is free to optimise away the redundant copy in this case.
BUT it does create a new object every time the function is invoked, and
it does seem like these objects are usable (I created a little test
program checking this :).
So basically I can go in main:

int main()
{
// ....
SomeObj bar = foo();
SomeObj bar2 = foo();
// for some strange reason the next thing will fail, though:
SomeObj &bar3 = foo();

You can't bind a temporary object (the function return) to a non-const
reference. Try

const SomeObj &bar3 = foo();

--
Ian Collins.

[Axel Bock]

Hi Ian,

you're right, this works. But why should that return value be a const?
I have declared const nowhere in the whole thing, and there's no
copying between the return value and the used object in main. So I
would say the function's return value is in fact not a temporary
object, and it being const is ... weird. I can modify bar and bar2 all
right ... :)

Basically I wonder about the object created in foo(), because should be
on the stack, in my opinion, and should be destroyed after the
function's scope ends.

But thanks, that answers one question, although replacing it with
another ;)

cheers,
Axel.

[mwhooker]

Alex,
I hope this answers your question. When an object goes out of scope, it
is destroyed. This doesn't necessarily mean that the memory is erased,
but if you decide to use the object, the behavior is undefined. So
while the object may still be on the stack, there are no guarantees
that it won't be overwriten.

-matt

[klaus hoffmann]

Axel Bock wrote:

Hi Ian,
Basically I wonder about the object created in foo(), because should be
on the stack, in my opinion, and should be destroyed after the
function's scope ends.

But thanks, that answers one question, although replacing it with
another ;)

cheers,
Axel.

Look for return value optimization.

SomeObj foo()
{
SomeObj X;
return X;
}
int main()
{
// ....
SomeObj bar = foo();
SomeObj bar2 = foo();
// for some strange reason the next thing will fail, though:
SomeObj &bar3 = foo();
}

The memory for bar and bar2 is allocated in main, and foo executes the
constructor for this object.
hth
Klaus

[Markus Schoder]

klaus hoffmann wrote:

Look for return value optimization.

SomeObj foo()
{
SomeObj X;
return X;
}

Is return value optimization allowed in this case? I thought it was
only possible for something like

SomeObj foo()
{
return SomeObj();
}

that is an unnamed object. Not sure though.

[Tomás]

Markus Schoder posted:

klaus hoffmann wrote:

Look for return value optimization.

SomeObj foo()
{
SomeObj X;
return X;
}

Is return value optimization allowed in this case? I thought it was
only possible for something like

SomeObj foo()
{
return SomeObj();
}

that is an unnamed object. Not sure though.

Yes, it's allowed in both cases above. If the expression after "return" can
used as an l-value, then you're likely to see optimization. For instance:

SomeClassType foo()
{
SomeObj x;

return ++x; //Likely to see optimization
}

SomeClassType foo()
{
SomeObj x;

return x++; //Less likely to see optimization
}
-Tomás

[Markus Schoder]

Tomás wrote:

Markus Schoder posted:

klaus hoffmann wrote:

Look for return value optimization.

SomeObj foo()
{
SomeObj X;
return X;
}

Is return value optimization allowed in this case?

Yes, it's allowed in both cases above. If the expression after "return" can
used as an l-value, then you're likely to see optimization. For instance:

SomeClassType foo()
{
SomeObj x;

return ++x; //Likely to see optimization
}

SomeClassType foo()
{
SomeObj x;

return x++; //Less likely to see optimization
}

Checked this now in the Standard. According to 12.8 (15) your examples
both cannot be optimized but the original one (with just return x;) can
indeed. The expression in the return statement has to be the name of a
local object.

[Axel Bock]

Hi all,

thanks for all the answers.
What I would like to clarify now is the "style" of that code: Is that
good style, or not?

I would rather say it's not, cause it surely LOOKS like a local object,
so using that is confusing. Maybe even compiler-dependent, for it is an
"optimizati on"? Anyways I do appreciate the ease of the assignment: To
have a function in which some init / creation / factory stuff can be
done, and assigning the return value without using copy constructors or
pointers. That on the other hand is good. Hm.

:-)

Anyways, cheers and thanks,
Axel.

[peter koch]

Axel Bock wrote:

Hi all,

thanks for all the answers.
What I would like to clarify now is the "style" of that code: Is that
good style, or not?
It is good style.

I would rather say it's not, cause it surely LOOKS like a local object,
so using that is confusing.
But it IS a local object. I see nothing confusing about that. What
would be truly confusing would be if assignment created a different
object than copy construction.
Maybe even compiler-dependent, for it is an
"optimizati on"?
You might call it an optimization, but one employed by all compilers i
know. Still the optimization should not change anything for the reasons
stated above.
Anyways I do appreciate the ease of the assignment: To
have a function in which some init / creation / factory stuff can be
done, and assigning the return value without using copy constructors or
pointers. That on the other hand is good. Hm.

/Peter