Copy constructors and clones

[Jay B. Harlow [MVP - Outlook]]

Jon,

Why should you use protected copy constructors internally to do it?
What do you have against MemberwiseClone? In fact, if you *do* use
protected copy constructors, you have a restriction that *everything*
in the type hierarchy has to have the appropriate copy constructor (or
risk losing private fields). MemberwiseClone just works.

Maybe this was addressed in the article Daniel posted the link to, which I
hope to get to read this week.

I don't see that MemberwiseClone is compatible with readonly instance
fields, if I want the readonly instance fields to be deep copied. Hence in
my project I went with a protected copy constructor. The project is largely
a closed system, so I don't have a problem with it per se.

Other then this cloning issue, are there other reasons I should consider
avoiding readonly instance fields? As you stated, I don't want to discuss
this in this thread, just wondering if you have any thinks to discussions on
readonly instance fields.

Thanks
Jay

 

[Jon Skeet [C# MVP]]

Jon,

Maybe this was addressed in the article Daniel posted the link to, which I
hope to get to read this week.

I don't see that MemberwiseClone is compatible with readonly instance
fields, if I want the readonly instance fields to be deep copied. Hence in
my project I went with a protected copy constructor. The project is largely
a closed system, so I don't have a problem with it per se.

Other then this cloning issue, are there other reasons I should consider
avoiding readonly instance fields? As you stated, I don't want to discuss
this in this thread, just wondering if you have any thinks to discussions on
readonly instance fields.

I don't, I'm afraid - I suspect you're in trouble in that situation,
unfortunately.

 

[Jon Skeet [C# MVP]]

The disadvantage which I see to your method is that one must know whether a
base class has already implemented MemberwiseClone in order to decide to
implement one's own Clone as either 1) MemberwiseClone followed by deep
copies or 2) base.Clone followed by deep copies. This to me means that one
has to simply know whether a base class has implemented Clone or not. If a
base class has implemented Clone your implementation calls the base class
Clone before doing any deep copying. If a base class has not implemented
Clone, your implementation does a MemberwiseClone before doing any deep
copy. N'est-ce pas, or did I miss something in this ? Of course
documentation will tell whether some base class has already implemented
Clone or not. But still it is something one needs to know as far as I can
see.

Yes, it is. And if the base class *later* starts implementing
ICloneable, you could have problems - although when you recompile
against the later version of the base class you'll get a compiler
warning. In fact, that's enough to see whether or not the base class
has its own Clone method - if you get a warning when you try to write

public virtual object Clone()

then you need to take a closer look at the base class

Jay's objection on the grounds of readonly fields is a good one
though... I don't know a decent way of fixing it