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.

[Ivan Vecerina]

"Markus Schoder" <a3************ *@yahoo.de> wrote in message
news:11******** **************@ i40g2000cwc.goo glegroups.com.. .
: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.

One may want "RAII"-style objects to be returned from functions,
if ownership-transfer semantics are implemented.
Think of std::auto_ptr
Of course, the latter is a bit of a hack in the current C++ standard,
but better support for the concept may soon be integrated in the
core language (look for proposals related to r-value references, the
latest version of which can be found here:
http://www.open-std.org/jtc1/sc22/wg...006/n1952.html ).

Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[peter koch]

Axel Bock skrev:

Hi Tomas,
[snip] @Squeamizh: Confused is what I was. Still, as I understood, what we
face here is a so-called "return-value-optimization". In that case the
compiler recognizes that this object you return gets assigned to a ...
variable in the calling (!) code, so it will perform all the actions,
but the resulting object will be global. Or in other words: Doing a

SomeObj obj = foo();

translates to something like:

SomeObj &obj;
if (this_or_that) {
// .... yadda ....
obj = /* something smart */
}
else if (blah ...)
{
//.....
obj = /* whatever */
}
/* basically all your foo-code */

(very, very roughly) explained. And all this because the compiler
actually realizes that the _local_ object gets returned and is to be
used in a wider scope.

What happens in practice whenever an object is returned from a function
is that the caller supplies memory for the returned object. Thus

SomeObj func()
{
SomeObj res;
...
returm res;
}

gets translated to

void func(void* area_suitable_f or_SomeObj).
{
SomeObj res;
...
new (area_suitable_ for_SomeObj) SomeObj(res);
}

Now, return value-optimisation allows the function above to be
implemented as:
void func(void* area_suitable_f or_SomeObj).
{
new (area_suitable_ for_SomeObj) SomeObj();
...
}

Notice that all functions that return an object will normally follow
the path above - irrespective of language. Pascal would do it the same
way. It is only when the object returned is small enough to fit into a
(few) register, that this way of passing is not used.

/Peter

[Axel Bock]

I see. Thanks a lot for that clarification! I now understand why is
happening what is happening ;)

cheers,
Axel.