By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,655 Members | 1,005 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,655 IT Pros & Developers. It's quick & easy.

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

P: n/a
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.

Dec 13 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
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
Dec 13 '05 #2

P: n/a
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 "unreferenced" 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.

Dec 13 '05 #3

P: n/a
ni*****@microsoft.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
Dec 13 '05 #4

P: n/a
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.)

Dec 13 '05 #5

P: n/a
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
Dec 13 '05 #6

P: n/a
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
Dec 13 '05 #7

P: n/a


ni*****@microsoft.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.

Dec 13 '05 #8

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


ni*****@microsoft.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**********@Home.com
Dec 13 '05 #9

P: n/a
Xiaoshen Li schrieb:
ni*****@microsoft.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
Dec 13 '05 #10

P: n/a
Thomas J. Gritzan wrote:
Xiaoshen Li schrieb:
ni*****@microsoft.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...


Nope. By the time 'lastYear' returns [to initialise 'bMoney'], the
reference it attempts to return has already become invalid, since the
object to which it referred has gone out of existence at the closing
curly brace of the 'lastYear's body.

bMoney.output();

This operates on a completly valid object.


Nope, since the initialisation of it had undefined behaviour, this point
in the program exists in a parallel universe, with completely different
laws of physics.
[..]


V
Dec 14 '05 #11

P: n/a
Xiaoshen Li wrote:
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.


No. It returns a null reference. There is no object of type Money in
that code. To return an object you have to create one:

Money tempMoney = new Money;

Similarly, in C++ you can use pointers:

Money *lastYear(Money *aMoney)
{
Money *tempMoney = new Money;
return tempMoney;
}

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Dec 26 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.