cast removal

[pepe]

Let's say that i have a method that does like clone(), but implements the cloning itself. That method does not return an Object instance, but an instance of the class itself. I think it it to remove the need to cast, for two reasons: speed and typing reduced.
I don't believe that doing so is clever, as duplicating processes for a task is a Bad Thing©, and can introduce bugs directly and during updates, but this is an other story.
My question at the moment is:
is the cast point valid? Wouldn't hotspot remove the cast when returning from clone() in a case as the one  below?

1	MyClass mc = (MyClass)myOtherClass.clone();

By the way... anyone ever benchmarked clone() opposed to hand done cloning?

[pepe]

is there something wrong with the question, or simply nobody knows?

[princec]

Maybe no-one knows. It's one of those things that's not likely to be a performance bottleneck anywhere I shouldn't think, either. I think that the cast is probably removable after the clone has been inlined.

Cas

Games published by our own members! Check 'em out!

[crystalsquid]

I don't think you even need the cast do you?

If MyOtherClass is derived from MyClass, then you should always be able to assign it to a base-class reference - at least you can in C++.

Casting the other way doen the inheritance tree is a different matter, and requires a cast and some care.

Speed wise I'm fairly certain that the cast would be more a compiler issue as opposed to generating any bytecodes from it - though I could be wrong on that too!  

- Dom

[kevglass]

Unfortunately clone() returns Object tho, so the cast is required.

Kev