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

[Chris Smith]

There is only need to implement Cloneable if you are going to use the
Object implementation of clone. There is not a pressing need to make
clone public (or add package private access when you override). Prior to
1.5, using a different method allows a useful return type. Using
Object.clone has dangers (admittedly, as does copying lots of fields one
by one).

Then again, using Object.clone() is the only reasonable way to get
correct object copying behavior in a non-final class with accessible
(protected or public) constructors. That's the fundamental reason to
use clone() instead of a copy constructor anyway... so yes, I'd say that
implementing Cloneable is fairly important.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Stefan Ram]

Chances are extremely good that the reference IS exactly the
memory address.

From the point of view of the JLS3, a "reference" is a term of
the specification of the language Java, while a "memory
address" is not. So the meaning of "reference" is specified,
while the meaning of "memory address" is not.

(JLS3 mentions "address" twice in 17.5.1, but this only
applies to the semantics of final fields.)

 

[Chris Smith]

From the point of view of the JLS3, a "reference" is a term of
the specification of the language Java, while a "memory
address" is not. So the meaning of "reference" is specified,
while the meaning of "memory address" is not.

(JLS3 mentions "address" twice in 17.5.1, but this only
applies to the semantics of final fields.)

Yes. Sort of like what I said in the very next paragraph, which you
snipped.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

You cannot assume that it is going to make sense to do a bitwise clone
of subclass fields. So in general, subclasses will need to override the
copy method, even if Cloneable is implemented.

Yes, that's true.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Thomas Hawtin]

Then again, using Object.clone() is the only reasonable way to get
correct object copying behavior in a non-final class with accessible
(protected or public) constructors. That's the fundamental reason to
use clone() instead of a copy constructor anyway... so yes, I'd say that
implementing Cloneable is fairly important.

You cannot assume that it is going to make sense to do a bitwise clone
of subclass fields. So in general, subclasses will need to override the
copy method, even if Cloneable is implemented.

Tom Hawtin

 

[Roedy Green]

Then again, using Object.clone() is the only reasonable way to get
correct object copying behavior in a non-final class with accessible
(protected or public) constructors. That's the fundamental reason to
use clone() instead of a copy constructor anyway... so yes, I'd say that
implementing Cloneable is fairly important.

clone won't let you promote or demote an object (add remove fields
moving down/up the hierarchy). It just gives you a copy of that you
already have.

e.g. Dog -> Dalmatian Dalmatian -> Dog

 

[Roedy Green]

Chances are extremely good
that the reference IS exactly the memory address.

In the early JVM a reference was a handle, the address of an
addresses. That was how the JVM planned to move objects around without
having to find and patch all the references to them.

 

[Chris Smith]

In the early JVM a reference was a handle, the address of an
addresses. That was how the JVM planned to move objects around without
having to find and patch all the references to them.

Yep, and as of the next generation JVM (HotSpot-based) and Java 1.2,
that is no longer the case. I am not aware of any commonly used VMs
(possibly excpting the Microsoft VM, if that's still commonly used) for
which the indirect handle technique is still used. However, I'm not
familiar with KVM... perhaps it's used there?

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[zero]

I don't understand what you mean here, zero. Chances are extremely
good that the reference IS exactly the memory address. The
relationship between the words "reference" and "memory address" is not
that they are alternatives to each other, but that a reference is an
abstraction that's very likely (almost certain, in fact) to be
implemented as a memory address.

So depending on whether you're talking within or outside the language
model, it is reasonable to say either that a method returns a
reference or a memory address, and it's almost certainly correct
(though not guaranteed as such by any spec) to say that a reference is
a memory address.

In C++ a pointer is a memory address, no discussion about that. However in
Java, like you said, a reference is not defined as being a memory address,
and could be implemented very differently in any VM. It is entirely
possible that it is indeed implemented as a direct memory location, but
saying that a java reference is a memory address does not hold true -
unless you're talking about a specific VM of which you know it to be true.
That's what I meant.

 

[Stefan Ram]

In C++ a pointer is a memory address, no discussion about that.

Then, why does the following programm print

true false

?

#include <iostream>
#include <ostream>
#include <iomanip>

class A { int a; }; class B { int b; };
class C : public A, public B {};

int main()
{ C * c = new C; B * b = c;
::std::cout << ::std::boolalpha <<
( b == c )<< ' ' << (( void * )b ==( void * )c ) << '\n'; }

 

[zero]

I'd say that a C++ pointer is to a memory address as a Java reference
is to a memory address. That is, the concepts are the same. The only
significant difference is that in C++, there have never been too
awfully many significant implementations for which it's not true. In
Java, such implementations have existed in the past, but not so much
any more (unless it's true of KVM, which I don't know for sure).

ok I guess there is discussion about that then I stand corrected.