Re: Function Returning a local object???

From: Old Wolf (oldwolf_at_inspire.net.nz)
Date: 09/07/04 

Date: 7 Sep 2004 14:30:34 -0700

50295@web.de (Olumide) wrote:
> Ok guys, thanks for the answers. I know its ok to return by value -
> for simple data types for example:
>
> int foo(){
> int number = 5;
> return 5;
> }
>
> int bar;
> bar = foo();
>
> This is no problem, because I can imagine the return value of foo()
> i.e. 5, being copied to the integer bar. But when the foo() returns a
> derived class class whose member variables are themselves class
> objects or worse still objects(?) of a derived class, I suspect there
> will be a fair amount of copying taking place when foo returns such a
> class by value. My question therefore how is this all the necessary
> copying handled??? By the overlaoded assignament operator, operator= ?
> If so, what happens is this operator= has not been defined by the
> programmer. Is it generated by the compiler? (I've read enough to know
> that the copy constructor is only invloved in the initialization of
> newly created variables, global or otherwise, but this is not the case
> here. All that's happening here is assignment.)

Actually the copy constructor is used here, "newly created
variables" includes temporary objects. When the function
returns, a temporary object is created (in the scope of the
calling function) using the copy-constructor, with the returned
value as parameter.
The calling function usually does something with this object,
eg. if it initializes another object then the copy-constructor
will be called again, with the temporary return-value object as
a parameter.
Being a temporary object, it will be destroyed at the end of the
full-expression it was created in, eg if we have at local scope:

   Foo func() { Foo g; return g; }
   Foo f( func() );

then we have:
  - g is default-constructed
  - temporary return value is copy-constructed from g
  - g is destroyed
  - f is copy-constructed from temporary return-value
  - temporary return-value is destroyed

The compiler is allowed to optimise all this, so you can't test
it with a compiler, but if you make Foo with a private copy
constructor then it should fail to compile.

Relevant Pages

  • Re: Does binding to const-reference outperform copy-initialization from returned value?
    ... const Foo constValue = GetFoo; ... the compiler is allowed to call Foo's copy-constructor ... const Foo& constReference = GetFoo; ...
    (microsoft.public.vc.language)
  • Re: a case for multiple inheritance
    ... and overrides the write functions to change ... the compiler would optimize it so that the double function call would be ... private new void Foo ... The cast not much ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: a case for multiple inheritance
    ... the compiler would optimize it so that the double function call would be ... private new void Foo ... The cast not much ... This means that if method A1 overrides ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: a case for multiple inheritance
    ... and overrides the write functions to change ... the compiler would optimize it so that the double function call would be ... private new void Foo ... The cast not much ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Operation can be dispatching in only one type
    ... to say that uninitialized is what the programmer wants. ... Some fancy means to tell the compiler that this variable ... So Java speculates that the default constructor is somewhat ... Yes, this is legal, because Foo is called with X having been ...
    (comp.lang.ada)