• Post Reply Bookmark Topic Watch Topic
  • New Topic

Cloning v/s Reference Copying  RSS feed

 
Naseem Khan
Ranch Hand
Posts: 809
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sir...

I hav a doubt regarding cloning v/s reference copying.
If u clone any object by java's clone method. It gives u copy of original object.
Say i hav simple code.

Clone Test c1=new CloneTest();
CloneTest c2=(Object)c1.clone(); // gets the clone of newly created object.

System.out.println("Original object " + c1 + " Cloned object " + c2);

here c1 and c2 both display same address. It means c1 and c2 are pointing to same object. Same behaviour u can get by jst reference copying like this.

CloneTest c1=new CloneTest(), c2;
c2=c1; //c1 and c2 prints same address after this line

so wat the difference between the two and wat is the power of cloning? I know its shallow copying.

plz help me!!!

Thanks and Regards

Naseem khan
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Naseem Khan:

Clone Test c1=new CloneTest();
CloneTest c2=(Object)c1.clone(); // gets the clone of newly created object.

System.out.println("Original object " + c1 + " Cloned object " + c2);

here c1 and c2 both display same address. It means c1 and c2 are pointing to same object.


If that is the case then you have implemented your clone() method incorrectly. Post the code for CloneTest.clone().
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good observation. It appears clone() is useless and in fact that is the case.

Here's the problem. If you implement the cloneable interface you have to copy variables from the original to the new object inside your clone method. Don't bother, however, because it will only work if your parent class does the same. If you can't do something reliably and consistently it's not much use.

Now, let's say you decide to use it anyway. The stipulation is that you call super.clone() on your parent. The clone() method is protected in Java, so it appears to be a problematic stipulation. Not so, the JVM breaks the contract and let's anybody call the protected clone() method as if it were public. It gives you an indication of what a badly thought out hack clone really is.

IMO it's better to provide a copy constructor and a copy method to implement a logical copy rather than pretending you can do deep copies of objects with the clone interface when you can't:

class Rocket
{
public int a;
private int b;
protected int c;

Rocket( Rocket source ) {
this.a = source.a;
this.b = source.b;
this.c = source.c;
}

Rocket copy( Rocket source ) { return new Rocket( source ); }

}
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rick O'Shay:
Good observation. It appears clone() is useless and in fact that is the case.


Wrong my friend. First to the OP, you must have botched your clone method as already posted here. Now to address Mr. O'Shay.

Originally posted by Rick O'Shay:
Here's the problem. If you implement the cloneable interface you have to copy variables from the original to the new object inside your clone method. Don't bother, however, because it will only work if your parent class does the same. If you can't do something reliably and consistently it's not much use.

The original members of the cloned class are automatically referenced by the newly created one when you call clone. So you don't have to do this copying you say. If your parent class does not provide 'cloneability' then as a decendent, you can not clone. C'est la vie.

Originally posted by Rick O'Shay:

Now, let's say you decide to use it anyway. The stipulation is that you call super.clone() on your parent. The clone() method is protected in Java, so it appears to be a problematic stipulation. Not so, the JVM breaks the contract and let's anybody call the protected clone() method as if it were public. It gives you an indication of what a badly thought out hack clone really is.

I don't know what you are trying to say here, but what you actually did say is not true.

Originally posted by Rick O'Shay:

IMO it's better to provide a copy constructor and a copy method to implement a logical copy rather than pretending you can do deep copies of objects with the clone interface when you can't:

class Rocket
{
public int a;
private int b;
protected int c;

Rocket( Rocket source ) {
this.a = source.a;
this.b = source.b;
this.c = source.c;
}

Rocket copy( Rocket source ) { return new Rocket( source ); }

}


But of course this fails



I think you are on the right track though. You need to mix the two approaches like so;


Voila
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Naseem Khan:


System.out.println("Original object " + c1 + " Cloned object " + c2);

here c1 and c2 both display same address. It means c1 and c2 are pointing to same object.


Perhaps the whole confusion is belonging to the word 'address' here.
How do you print addresses, Sir?
[ August 27, 2005: Message edited by: Stefan Wagner ]
 
Ronnie Ho
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good observation Stefan, i think Naseem may have mis-understood the hashcode as the memory address of the object referenced.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ronnie Ho:
Good observation Stefan, i think Naseem may have mis-understood the hashcode as the memory address of the object referenced.


He probably did, but that misunderstanding did not lead him to any false conclusions!?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!