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.

[Tomás]

The problem is that you ignore possible side effects in the copy
constructor and the destructor.

If the classes with which you are working were written "properly", then the
sideeffects of a copy-construction/destruction should be irrelevant. All
you should notice is that the execution time goes up on account of invoking
the copy constructor and subsequently, the destructor.
-Tomás

[Axel Bock]

Hi all,

first of all thanks for all that information :) . But what I want to
clarify still is that _there is no copying taking place_.

In my logic, if an object gets copied, the copy constructor is used. I
implemented this one with a textual message, and this one gets never,
ever called. In the example that means that

SomeObj obj = foo();

does create an object in the foo() function, which will be assigned
directly to obj. No copying. Also it is the same object by pointer, I
compared the values. Hm.

Again: NO copying there. That's what irritated me.

:-) .
Cheers,

Axel.

[Richard Herring]

In message <11************ **********@v46g 2000cwv.googleg roups.com>, Axel
Bock <ax************ @googlemail.com > writes

Hi all,

first of all thanks for all that information :) . But what I want to
clarify still is that _there is no copying taking place_.

In my logic, if an object gets copied, the copy constructor is used. I
implemented this one with a textual message, and this one gets never,
ever called. In the example that means that

SomeObj obj = foo();

does create an object in the foo() function, which will be assigned
Not _assigned_. The assignment operator isn't used either.
directly to obj. No copying. Also it is the same object by pointer, I
compared the values. Hm.

Again: NO copying there. That's what irritated me.

:-) .
Cheers,

Axel.

--
Richard Herring

[Kai-Uwe Bux]

Axel Bock wrote:

Hi all,

first of all thanks for all that information :) . But what I want to
clarify still is that _there is no copying taking place_.

In my logic, if an object gets copied, the copy constructor is used. I
implemented this one with a textual message, and this one gets never,
ever called. In the example that means that

SomeObj obj = foo();

does create an object in the foo() function, which will be assigned
directly to obj. No copying. Also it is the same object by pointer, I
compared the values. Hm.

Again: NO copying there. That's what irritated me.

Here is some relevant language 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.11 1) 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

[Example:
class Thing {
public:
Thing();
?Thing();
Thing(const Thing&);
};

Thing f() {
Thing t;
return t;
}

Thing t2 = f();

Here the criteria for elision can be combined to eliminate two calls to
the copy constructor of class Thing: the copying of the local automatic
object t into the temporary object for the return value of function f()
and the copying of that temporary object into object t2. Effectively, the
construction of the local object t can be viewed as directly initializing
the global object t2, and that object?s destruction will occur at program
exit. ?end example]
Best

Kai-Uwe Bux

[Gavin Deane]

Roland Pibinger wrote:

On 12 Apr 2006 04:41:13 -0700, "Gavin Deane" <de*********@ho tmail.com>
wrote:

So what can a programmer do differently if they know return value
optimisation will be performed? Nothing. There is no code you can write
that would only be correct if return value optimisation were performed.
There is nothing you can write in main to violate the scoping rules
that apply to X and bar if the optimisation is performed. So there is
no problem with this style.

The problem is that you ignore possible side effects in the copy
constructor and the destructor.

That's a different point. I was addressing the OP's apparent concern
that there is something somehow unsafe about return value optimisation.

Your point is only a problem if you write copy constructors and
destructors with side effects. *If* you do that, *and* it is necessary
that the side effects happen, clearly you must avoid using objects of
that type in any situation where the language allows temporary copies
to be elided. Depending on the particular situation, a rethink of the
design may be a better long-term solution.

Gavin Deane

[peter koch]

Axel Bock skrev:

Hi all,

first of all thanks for all that information :) . But what I want to
clarify still is that _there is no copying taking place_.
Right. The standard says so, so it should not be to surprising.
In my logic, if an object gets copied, the copy constructor is used. I
implemented this one with a textual message, and this one gets never,
ever called. In the example that means that

SomeObj obj = foo();

does create an object in the foo() function, which will be assigned
directly to obj. No copying. Also it is the same object by pointer, I
compared the values. Hm.
First of all, the fact that you did notice in the first place is what
should really worry you. This means that you use the assignment
operator for something that is not assignment. While this technically
is legal it is confusing in the same way as if you used operator+ to do
division,
Secondly, I wonder (wearing my technical glasses) how you can be so
sure that it is the same object. That they have the same adress does
not imply they are equal. Memory IS allowed to be reused, you know -
much to the discontent of the RAM-producers.

/Peter
Again: NO copying there. That's what irritated me.

:-) .
Cheers,

Axel.

[pillbug]

The following code calls a constructor and a destructor.

void fn1 (void)
{
Object obj;
}

The following code has a constructor call for the local object, followed
by a copy constructor for the return, and then a destructor for the
local object.

Object fn2 (void)
{
Object obj;
return obj;
}

The following code has a constructor call, followed by a copy constructor.

Object fn3 (void)
{
return *new Object; // "bad" style :)
}

In fn2 the compiler is allowed to omit the copy by constructing the
object "in-place" of the return value; in MSVC this is accomplished by
passing in the address to construct the object. This is a desirable
effect.

[Roland Pibinger]

On Thu, 13 Apr 2006 05:28:02 -0400, Kai-Uwe Bux <jk********@gmx .net>
wrote:

Here is some relevant language 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.

It's astonishing that Stroustrup let that slip into the language.

[Tomás]

Roland Pibinger posted:

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.

It's astonishing that Stroustrup let that slip into the language.

I disagree entirely -- I think it paves the way for more efficient
programming.

If a class has "side effects" because of a copy constructor or destructor,
then it's a stupid class.

-Tomás

[Markus Schoder]

Tomás wrote:

Roland Pibinger posted:

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.
It's astonishing that Stroustrup let that slip into the language.

I disagree entirely -- I think it paves the way for more efficient
programming.

I also think RVO is a win.
If a class has "side effects" because of a copy constructor or destructor,
then it's a stupid class.

Maybe true for the copy constructor for the destructor however side
effects are not uncommon the whole RAII concept cannot work without
them (think std::fstream or classes for mutex locking). Of course these
are not objects you would normally return from a function.