question--A function returns class object(comparin g C++ & JAVA)

[Xiaoshen Li]

Dear Sir,

I am a little puzzled about a function returning a class object, for
example, suppose I hava a class Money and a method:

Money lastYear(Money aMoney)
{
Money tempMoney;
...
return tempMoney;
}

Because in C++ the RETURNED is actually a new copy of the object(kind of
like passing by value), here a copy of tempMoney is returned, so
tempMoney will be useless, so after the statement of return, the object
tempMoney will be destroyed. Is this correct?

Now, if in JAVA(sorry, not offending), since always passing by
reference, if above code is Java, the RETURNED is the MEMORY ADDRESS of
the object tempMoney. So after the exit of the function, the object
tempMoney is referenced by other variable. So it stays existing. Is this
correct?

Thank you very much.

[Victor Bazarov]

Xiaoshen Li wrote:

I am a little puzzled about a function returning a class object, for
example, suppose I hava a class Money and a method:

Money lastYear(Money aMoney)
{
Money tempMoney;
...
return tempMoney;
}

Because in C++ the RETURNED is actually a new copy of the object(kind of
like passing by value), here a copy of tempMoney is returned, so
tempMoney will be useless, so after the statement of return, the object
tempMoney will be destroyed. Is this correct?
'tempMoney' is a local object. It will be destroyed when 'lastYear'
function finishes execution no matter what (or how) you return.
Now, if in JAVA(sorry, not offending), since always passing by
reference, if above code is Java, the RETURNED is the MEMORY ADDRESS of
the object tempMoney.
I'll take your word for it.
So after the exit of the function, the object
tempMoney is referenced by other variable. So it stays existing. Is this
correct?

Why don't you ask about Java internals in a Java newsgroup?

V

[niklasb]

Victor Bazarov wrote:

Xiaoshen Li wrote:

I am a little puzzled about a function returning a class object, for
example, suppose I hava a class Money and a method:

Money lastYear(Money aMoney)
{
Money tempMoney;
...
return tempMoney;
}

Because in C++ the RETURNED is actually a new copy of the object(kind of
like passing by value), here a copy of tempMoney is returned, so
tempMoney will be useless, so after the statement of return, the object
tempMoney will be destroyed. Is this correct?

'tempMoney' is a local object. It will be destroyed when 'lastYear'
function finishes execution no matter what (or how) you return.

To the OP, you're correct that tempMoney is destroyed, but if by
"useless" you mean "unreferenc ed" then I suspect you may have
misunderstood the reason.

As Victor pointed out, tempMoney is destroyed as soon as it
passes out of scope simply because it is a local object. It has
nothing to do with whether any references to the object still
exist. For example, if you were unwise, you could have written:

// oops! returns a dangling reference
Money& lastYear(Money aMoney)
{
Money tempMoney;
....
return tempMoney;
}

In this case, tempMoney is still destroyed and the reference
returned by the function is bound to a non-existent object.
Unlike in Java, the existence of a reference has no impact on
the lifetime of the referenced object. Likewise, a pointer does
not affect the lifetime of the pointee. It's up to you to make
sure there are no dangling references or pointers.

[Victor Bazarov]

ni*****@microso ft.com wrote:

[...]
Unlike in Java, the existence of a reference has no impact on
the lifetime of the referenced object.
Actually this is not generally true. If a temporary object has a const
reference bound to it, the temporary persists as long as the reference.
But the lifetime of a temporary is maintained at compile-time, not at
run-time. It's a special case, of course. And you're absolutely right
WRT pointers.
[..]

V

[Xiaoshen Li]

Thank you so much for helping me. I just got another question.

In C++, suppose with class Money:
Money aMoney, bMoney;
....
bMoney = aMoney;

Now bMoney refers to an identical object with aMoney refers to. But they
are two separate objects(but identical).

Is there a way to make bMoney refers to the SAME object as aMoney refers
to? (This question may be too simple to ask. Sorry, my mind is clogging.)

[Thomas J. Gritzan]

Xiaoshen Li schrieb:

Thank you so much for helping me. I just got another question.

In C++, suppose with class Money:
Money aMoney, bMoney;
...
bMoney = aMoney;

Now bMoney refers to an identical object with aMoney refers to. But they
are two separate objects(but identical).

Is there a way to make bMoney refers to the SAME object as aMoney refers
to? (This question may be too simple to ask. Sorry, my mind is clogging.)

Money aMoney;
Money &bMoney = aMoney;
Thomas

[Victor Bazarov]

Xiaoshen Li wrote:

Thank you so much for helping me. I just got another question.

In C++, suppose with class Money:
Money aMoney, bMoney;
...
bMoney = aMoney;

Now bMoney refers to an identical object with aMoney refers to. But they
are two separate objects(but identical).
Since C++ has 'reference' type, and also 'iterator' and 'pointer' that can
actually _refer_ (or point) to something, let's avoid using that term here
because it can lead to confusion. 'bMoney' does not refer, it designates.
So, we should say 'bMoney' designates a separate object. Now, whether
they are truly identical is up for debate because we don't know how class
'Money' is implemented and what its 'operator=' actually does.
Is there a way to make bMoney refers to the SAME object as aMoney refers
to? (This question may be too simple to ask. Sorry, my mind is clogging.)

Money aMoney;
Money &bMoney = aMoney; // bMoney is a reference

There is no other way.

V

[Xiaoshen Li]

ni*****@microso ft.com wrote:

As Victor pointed out, tempMoney is destroyed as soon as it
passes out of scope simply because it is a local object. It has
nothing to do with whether any references to the object still
exist. For example, if you were unwise, you could have written:

// oops! returns a dangling reference
Money& lastYear(Money aMoney)
{
Money tempMoney;
....
return tempMoney;
}

In this case, tempMoney is still destroyed and the reference
returned by the function is bound to a non-existent object.
Unlike in Java, the existence of a reference has no impact on
the lifetime of the referenced object. Likewise, a pointer does
not affect the lifetime of the pointee. It's up to you to make
sure there are no dangling references or pointers.

I became so interested in seeing this so I wrote code to test it. BUT,
the results is not what you said. (I truely believe you are correct!).
With following function:

Money& lastYear(Money aMoney)
{
Money tempMoney;
tempMoney = aMoney;
return tempMoney;
}

Money bMoney = lastYear(aMoney );
bMoney.output() ;

I got warning when compiling. But running actually went through and
output() printed out the "correct" value, the same value as aMoney.
Based on what you said above, I would expect bMoney.output() prints out
garbage, since bMoney binds to a non-existent object. Could you give me
more help?

Thank you very much.

[Bob Hairgrove]

On Tue, 13 Dec 2005 19:35:50 +0000, Xiaoshen Li <xl**@gmu.edu > wrote:

ni*****@micros oft.com wrote:

As Victor pointed out, tempMoney is destroyed as soon as it
passes out of scope simply because it is a local object. It has
nothing to do with whether any references to the object still
exist. For example, if you were unwise, you could have written:

// oops! returns a dangling reference
Money& lastYear(Money aMoney)
{
Money tempMoney;
....
return tempMoney;
}

In this case, tempMoney is still destroyed and the reference
returned by the function is bound to a non-existent object.
Unlike in Java, the existence of a reference has no impact on
the lifetime of the referenced object. Likewise, a pointer does
not affect the lifetime of the pointee. It's up to you to make
sure there are no dangling references or pointers.

I became so interested in seeing this so I wrote code to test it. BUT,
the results is not what you said. (I truely believe you are correct!).
With following function:

Money& lastYear(Money aMoney)
{
Money tempMoney;
tempMoney = aMoney;
return tempMoney;
}

Money bMoney = lastYear(aMoney );
bMoney.output( );

I got warning when compiling. But running actually went through and
output() printed out the "correct" value, the same value as aMoney.
Based on what you said above, I would expect bMoney.output() prints out
garbage, since bMoney binds to a non-existent object. Could you give me
more help?

It is possible that bMoney.output() prints out the expected value, or
just as possible that it prints out garbage, or just as possible that
it sends an e-mail to your girlfriends' husband telling him what you
did last weekend <g>. This is called "undefined behavior", and
ANYTHING is possible when you have undefined behavior.

--
Bob Hairgrove
No**********@Ho me.com

[Thomas J. Gritzan]

Xiaoshen Li schrieb:

ni*****@microso ft.com wrote:

In this case, tempMoney is still destroyed and the reference
returned by the function is bound to a non-existent object.
Unlike in Java, the existence of a reference has no impact on
the lifetime of the referenced object. Likewise, a pointer does
not affect the lifetime of the pointee. It's up to you to make
sure there are no dangling references or pointers.

I became so interested in seeing this so I wrote code to test it. BUT,
the results is not what you said. (I truely believe you are correct!).
With following function:

Money& lastYear(Money aMoney)
{
Money tempMoney;
tempMoney = aMoney;
return tempMoney;
}

Money bMoney = lastYear(aMoney );

Here you are copying the object into another object so that...
bMoney.output() ;
This operates on a completly valid object.
I got warning when compiling. But running actually went through and
output() printed out the "correct" value, the same value as aMoney.
Based on what you said above, I would expect bMoney.output() prints out
garbage, since bMoney binds to a non-existent object. Could you give me
more help?

Try this:

Money &bMoney = lastYear(aMoney );
bMoney.output() ;

bMoney will refer to the local variable in lastYear which is no more
valid. You get undefined behavier. "undefined" means here that
everything could happen, including that the "correct" values are printed
out in the case that these values are not overwritten yet.

Thomas