Copy constructors and clones

[Edward Diener]

Coming from the C++ world I can not understand the reason why copy
constructors are not used in the .NET framework. A copy constructor creates
an object from a copy of another object of the same kind. It sounds simple
but evidently .NET has difficulty with this concept for some reason. I do
understand that .NET objects are created on the GC heap but that doesn't
mean that they couldn't be copied from another object of the same kind when
they are created.

I understand that .NET has an ICloneable interface which is used to make a
deep copy of an object, and that it even has a protected MemberWiseClone to
be used internally for shallow copies. But much to my surprise even
ICloneable.Clon e() is sometimes not used to make a deep copy of an object
but some other particular class member function is used instead.

As an example when I look at the system.string class I find that it does not
have a copy constructor, which for whatever reason I do not understand seems
normal for .NET. Then I look at the Clone() function, expecting it to make a
copy of the string's contents and return it to me as a new string. No, it
doesn't do that either. Finally I find the Copy() function which does the
job. So instead of creating a new string from an old one, I must do the
arcane ( for me ) 'string x = string.Copy(old _instance);' rather than a
simple 'string x = new string(old_inst ance)'.

Comments and explanations ?

[Cor]

Hi Edward

VB.net
dim newstring as string = oldstring
C#
string newstring = oldstring;
C++ as you said
string newstring = new string(oldstrin g)

I think you love to type?

Comments:

Never try to use your used old statements from you used language.

Example, once someone told me that in his language he only used 50 code for
a sort, he had translated it to the one I was using then and he 200 lines of
code

He had not seen that there was a statemen "sort" from one line.
(It was also much faster)

Cor

Coming from the C++ world I can not understand the reason why copy
constructors are not used in the .NET framework. A copy constructor creates an object from a copy of another object of the same kind. It sounds simple
but evidently .NET has difficulty with this concept for some reason. I do
understand that .NET objects are created on the GC heap but that doesn't
mean that they couldn't be copied from another object of the same kind when they are created.

I understand that .NET has an ICloneable interface which is used to make a
deep copy of an object, and that it even has a protected MemberWiseClone to be used internally for shallow copies. But much to my surprise even
ICloneable.Clon e() is sometimes not used to make a deep copy of an object
but some other particular class member function is used instead.

As an example when I look at the system.string class I find that it does not have a copy constructor, which for whatever reason I do not understand seems normal for .NET. Then I look at the Clone() function, expecting it to make a copy of the string's contents and return it to me as a new string. No, it
doesn't do that either. Finally I find the Copy() function which does the
job. So instead of creating a new string from an old one, I must do the
arcane ( for me ) 'string x = string.Copy(old _instance);' rather than a
simple 'string x = new string(old_inst ance)'.

Comments and explanations ?

[Bruno Jouhier [MVP]]

> As an example when I look at the system.string class I find that it does
not

have a copy constructor, which for whatever reason I do not understand seems normal for .NET. Then I look at the Clone() function, expecting it to make a copy of the string's contents and return it to me as a new string. No, it
doesn't do that either. Finally I find the Copy() function which does the
job. So instead of creating a new string from an old one, I must do the
arcane ( for me ) 'string x = string.Copy(old _instance);' rather than a
simple 'string x = new string(old_inst ance)'.

Strings are immutable. So you are basically wasting memory if you copy them.
Copying is only interesting if you can get a mutable copy.

Bruno.

[Edward Diener]

Cor wrote:

Hi Edward

VB.net
dim newstring as string = oldstring
C#
string newstring = oldstring;
This assigns the reference of the oldstring to the newstring. It does not do
a copy.
C++ as you said
string newstring = new string(oldstrin g)
Wrong syntax. It would have to be:

String * newstring = new String(oldstrin g);

I don't see a constructor like this in the documentation. Does it really
exist for making a copy ? If so it is not documented.

I think you love to type?
No, I hate to type. That is why I brought up the subject in the first place.
I also find copy constructors easy to use in C++. However the example you
gave for C# does not do a copy and the corrected example for C++ does not
exist AFAIK. I don't know VB but I am guessing that it doesn't do a copy
either but rather creates another reference.

Comments:

Never try to use your used old statements from you used language.

Example, once someone told me that in his language he only used 50
code for a sort, he had translated it to the one I was using then and
he 200 lines of code

He had not seen that there was a statemen "sort" from one line.
(It was also much faster)

Cor

Coming from the C++ world I can not understand the reason why copy
constructors are not used in the .NET framework. A copy constructor
creates an object from a copy of another object of the same kind. It
sounds simple but evidently .NET has difficulty with this concept
for some reason. I do understand that .NET objects are created on
the GC heap but that doesn't mean that they couldn't be copied from
another object of the same kind when they are created.

I understand that .NET has an ICloneable interface which is used to
make a deep copy of an object, and that it even has a protected
MemberWiseClone to be used internally for shallow copies. But much
to my surprise even ICloneable.Clon e() is sometimes not used to make
a deep copy of an object but some other particular class member
function is used instead.

As an example when I look at the system.string class I find that it
does not have a copy constructor, which for whatever reason I do not
understand seems normal for .NET. Then I look at the Clone()
function, expecting it to make a copy of the string's contents and
return it to me as a new string. No, it doesn't do that either.
Finally I find the Copy() function which does the job. So instead of
creating a new string from an old one, I must do the arcane ( for me
) 'string x = string.Copy(old _instance);' rather than a simple
'string x = new string(old_inst ance)'.

Comments and explanations ?

[Codemonkey]

Cor,

As a string is a reference type, "dim newstring as string = oldstring"
causes "newstring" to point to the same string instance as "oldstring" (as
can be demonstrated by the Is operator). Some may mistakenly think that they
point to different instances because if you change "newstring" , "oldstring"
doesn't change - this is because a string is immutable, not because there
are two string instances containing the same characters. If you done this
with an object that is not immutable, then it is not a copy, simply another
reference to the same object (unless you use a value type).

Back to Edwards question, I think that the lack of copy constructors in .net
is more of an oversight in the implementation of the object that you are
using, rather than a missing feature in the languages. Personally, I think
ICloneable is suitable - afterall not all objects can be cloned - those that
can't be cloned simply do not implement ICloneable. Also, there is nothing
to stop you implementing a copy constructor in your own objects.

As far as the documentation for the Clone method of a string is concerned it
states:

"The return value is not an independent copy of this instance; it is simply
another view of the same data. Use the Copy or CopyTo method to create a
separate String object with the same value as this instance."

Which kinda defeats the purpose of the Clone method in my opinion, but I
guess they had their reasons (probably because a string is immutable, so
changes will not affect other references to the same instance).

HTH,

Trev.

[Jay B. Harlow [MVP - Outlook]]

Edward,
In addition to Cor's comments.

There is nothing stopping you from defining a copy constructor in your
classes! In fact I use (protected) copy constructors to implement my Clone
methods in one of my projects, as you have to if you want to use read-only
fields in your class. :-) Read-only fields can only be set in the
constructor, MemberWiseCopy was not an option as I need a deep copy...

IMHO The biggest advantage that the Clone Pattern has over copy constructors
is that the Clone pattern can be polymorphic. You can define Clone as
virtual/overridable in the base class, and offer implementation in the
derived classes. The other code can create a copy of that object, with only
a reference to the base object!

IMHO The second biggest advantage is consistency. If you need Clone for
polymorphism, having some classes implement clone while others implement
pure copy constructors leads to somewhat inconsistent code. Having all
objects that can be 'copied' implement the Clone pattern leads to code that
is quicker to understand (unless of course you can from a C++ background
;-)). Note some classes support Clone & Copy methods. Where Clone does a
"shallow" copy, while Copy does a "deep" copy. In addition to your String
example see System.Data.Dat aSet & System.Data.Dat aTable for examples.

IMHO the one danger of copy constructors are in class hierarchies like
System.IO.Strea m. Is the stream object passed to the constructor of a
derived stream intended for a copy or are you implementing a
Composite/Delegate Pattern?

I want to say there are a handful of classes in the Framework that support
copy constructors, however I don't remember specifically which ones.

As an example when I look at the system.string class I find that it does not
Remember that String is immutable reference type, I have yet to need to make
a copy of the contents of a string. I would do as Cor stated.

String x = old_instance

And live with the reference. In fact I would prefer to have the reference,
as it performs better & is easier on Memory consumption...

Hope this helps
Jay

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** *******@tk2msft ngp13.phx.gbl.. . Coming from the C++ world I can not understand the reason why copy
constructors are not used in the .NET framework. A copy constructor creates an object from a copy of another object of the same kind. It sounds simple
but evidently .NET has difficulty with this concept for some reason. I do
understand that .NET objects are created on the GC heap but that doesn't
mean that they couldn't be copied from another object of the same kind when they are created.

I understand that .NET has an ICloneable interface which is used to make a
deep copy of an object, and that it even has a protected MemberWiseClone to be used internally for shallow copies. But much to my surprise even
ICloneable.Clon e() is sometimes not used to make a deep copy of an object
but some other particular class member function is used instead.

As an example when I look at the system.string class I find that it does not have a copy constructor, which for whatever reason I do not understand seems normal for .NET. Then I look at the Clone() function, expecting it to make a copy of the string's contents and return it to me as a new string. No, it
doesn't do that either. Finally I find the Copy() function which does the
job. So instead of creating a new string from an old one, I must do the
arcane ( for me ) 'string x = string.Copy(old _instance);' rather than a
simple 'string x = new string(old_inst ance)'.

Comments and explanations ?

[Edward Diener]

Bruno Jouhier [MVP] wrote:

As an example when I look at the system.string class I find that it
does not have a copy constructor, which for whatever reason I do not
understand seems normal for .NET. Then I look at the Clone()
function, expecting it to make a copy of the string's contents and
return it to me as a new string. No, it doesn't do that either.
Finally I find the Copy() function which does the job. So instead of
creating a new string from an old one, I must do the arcane ( for me
) 'string x = string.Copy(old _instance);' rather than a simple
'string x = new string(old_inst ance)'.

Strings are immutable. So you are basically wasting memory if you
copy them. Copying is only interesting if you can get a mutable copy.

You are correct. Definitely my error for not realizing this.

[Edward Diener]

Codemonkey wrote:

Cor,

As a string is a reference type, "dim newstring as string = oldstring"
causes "newstring" to point to the same string instance as
"oldstring" (as can be demonstrated by the Is operator). Some may
mistakenly think that they point to different instances because if
you change "newstring" , "oldstring" doesn't change - this is because
a string is immutable, not because there are two string instances
containing the same characters. If you done this with an object that
is not immutable, then it is not a copy, simply another reference to
the same object (unless you use a value type).
Yes, what I said in my reply. You gave an example of a reference assignment
and not a copy.

Back to Edwards question, I think that the lack of copy constructors
in .net is more of an oversight in the implementation of the object
that you are using, rather than a missing feature in the languages.
IMHO copy constructors are an easy way to construct a new object from an old
object of the same type.
Personally, I think ICloneable is suitable - afterall not all objects
can be cloned - those that can't be cloned simply do not implement
ICloneable.
And if an object is not cloneable, .NET objects should not implement a copy
constructor. The same argument holds.
Also, there is nothing to stop you implementing a copy
constructor in your own objects.
Of course not, but why the .NET framework objects don't have them was the
original query.

As far as the documentation for the Clone method of a string is
concerned it states:

"The return value is not an independent copy of this instance; it is
simply another view of the same data. Use the Copy or CopyTo method
to create a separate String object with the same value as this
instance."

Which kinda defeats the purpose of the Clone method in my opinion,
but I guess they had their reasons (probably because a string is
immutable, so changes will not affect other references to the same
instance).

I was wrong to bring up string. Since it is immutable, making a copy of it
is a waste of time. I now realize this. But having copy constructors for
mutable objects still seems like a good idea to me and I am still surprised
mutable FCL classes do not have them.

[Edward Diener]

Jay B. Harlow [MVP - Outlook] wrote:

Edward,
In addition to Cor's comments.

There is nothing stopping you from defining a copy constructor in your
classes!
Of course not.
In fact I use (protected) copy constructors to implement my
Clone methods in one of my projects, as you have to if you want to
use read-only fields in your class. :-) Read-only fields can only be
set in the constructor, MemberWiseCopy was not an option as I need a
deep copy...
I agree.

IMHO The biggest advantage that the Clone Pattern has over copy
constructors is that the Clone pattern can be polymorphic. You can
define Clone as virtual/overridable in the base class, and offer
implementation in the derived classes. The other code can create a
copy of that object, with only a reference to the base object!
I don't see how ICloneable::Clo ne being polymorphic helps at all. Can you
give me an example ? I find it exactly otherwise and I see it hindering
things since I can not use the cloned object of a base class in my derived
class Clone(), since the base class
Clone() creates a separate object reference to the base class for me and yet
my derived class's Clone() has to return a reference to my derived class. So
in my Clone() for a derived class I must repeat everything I am doing in my
base class's Clone() plus any member variables that need to be cloned for my
derived class.

OTOH copy constructors have no such problems and are actually polymorphic by
nature. If my base class has a copy constructor, I simply call the base
class copy constructor passing the other object that needs to be copied to
the base class, then I copy any other non-base fields from the copied object
to my own. This is much easier and more natural than implementing Clone() in
a class hierarchy.

IMHO The second biggest advantage is consistency. If you need Clone
for polymorphism, having some classes implement clone while others
implement pure copy constructors leads to somewhat inconsistent code.
I can understand this as an inconsistency but I would rather have copy
constructors than cloneable objects ( see above ). The one advantage of
ICloneable as an interface is that one can test for it in code to see if an
object is cloneable. But I see little advantage for this at run-time.
Having all objects that can be 'copied' implement the Clone pattern
leads to code that is quicker to understand (unless of course you can
from a C++ background ;-)).
The smiley is noted. For C++ programmers copy constructors are much easier
to use and program. I still think they are in any application framework.
Note some classes support Clone & Copy
methods. Where Clone does a "shallow" copy, while Copy does a "deep"
copy. In addition to your String example see System.Data.Dat aSet &
System.Data.Dat aTable for examples.
Yes, now that is confusing <g> .

IMHO the one danger of copy constructors are in class hierarchies like
System.IO.Strea m. Is the stream object passed to the constructor of a
derived stream intended for a copy or are you implementing a
Composite/Delegate Pattern?
That is what documentation is all about. Normally the same object passed to
a copy constructor is always for copy however. If you need a composite, the
object can be passed in a member function.

I want to say there are a handful of classes in the Framework that
support copy constructors, however I don't remember specifically
which ones.
There may be some AFAIK but generally FCL does not support the idea of copy
constructors. Which is something I find a bit strange.

As an example when I look at the system.string class I find that it
does not
Remember that String is immutable reference type, I have yet to need
to make a copy of the contents of a string. I would do as Cor stated.

String x = old_instance

And live with the reference. In fact I would prefer to have the
reference, as it performs better & is easier on Memory consumption...

This was definitely my mistake in using an immutable object as an example.
String doesn't need a copy constructor and even the String::Copy member
function seems a waste of time to me.

Hope this helps
Except for the ICloneable interface telling code at run-time that an object
is cloneable, I don't see eveidence that it is preferable to copy
constructors and all my experience points the other way. I will be glad to
look at evidence which favors ICloneable if you would like to present it.
Sometimes older, time-tested ideas are best.
Jay

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** *******@tk2msft ngp13.phx.gbl.. .

Coming from the C++ world I can not understand the reason why copy
constructors are not used in the .NET framework. A copy constructor
creates an object from a copy of another object of the same kind. It
sounds simple but evidently .NET has difficulty with this concept
for some reason. I do understand that .NET objects are created on
the GC heap but that doesn't mean that they couldn't be copied from
another object of the same kind when they are created.

I understand that .NET has an ICloneable interface which is used to
make a deep copy of an object, and that it even has a protected
MemberWiseClone to be used internally for shallow copies. But much
to my surprise even ICloneable.Clon e() is sometimes not used to make
a deep copy of an object but some other particular class member
function is used instead.

As an example when I look at the system.string class I find that it
does not have a copy constructor, which for whatever reason I do not
understand seems normal for .NET. Then I look at the Clone()
function, expecting it to make a copy of the string's contents and
return it to me as a new string. No, it doesn't do that either.
Finally I find the Copy() function which does the job. So instead of
creating a new string from an old one, I must do the arcane ( for me
) 'string x = string.Copy(old _instance);' rather than a simple
'string x = new string(old_inst ance)'.

Comments and explanations ?

[Cor]

Hi Edward,

This was definitely my mistake in using an immutable object as an example.
String doesn't need a copy constructor and even the String::Copy member
function seems a waste of time to me.

And therefore I was so fast with my answer, with a smile on my face when I
was writting it.

:-))

Cor