Copy constructor

[Guest]

In C++ we have a copy constructor. What is the equivalent in .Net? Would that
be a clone method?

 

[Nicholas Paldino [.NET/C# MVP]]

Arne,

The IClonable interface is the closest thing to a copy constructor.
However, you have to manually invoke the Clone method on the IClonable
interface, it doesn't get called for you on assignment.

Hope this helps.

 

[Ollie Riches]

in .net you can still have a copy constructor, usually in my experience the
Clone method usually calls the copy constructor internally - whether the
copy constructor is public\protected\private is up to you i guess.

HTH

Ollie Riches

 

[Jeff Louie]

Arne... Be very careful here. C++ objects use value semantics by
default. NOT so in C#. C# objects use reference semantics so there is no
"copy constructor" on assignment. The closest thing to value semantics
in C# is a struct, which does not support inheritance. Also in managed
C++ 2.0 there is built in support for deterministic behavior of objects.

Regards,
Jeff
In C++ we have a copy constructor. What is the equivalent in .Net? Would
that be a clone method?

 

[Guest]

This puzzles me. First of all, saying "The IClonable interface is the closest
thing to a copy constructor" implies that there is no copy constructor in C#,
which of course there is.
So what is the difference between ICloneable and a copy constructor. There
appears to be none, in which case what is the purpose of ICloneable? Ollie
Riches says "usually in my experience the Clone method usually calls the copy
constructor internally" - so why bother with ICloneable at all if a public
copy constructor would be just as good?
--
Dave

Arne,

The IClonable interface is the closest thing to a copy constructor.
However, you have to manually invoke the Clone method on the IClonable
interface, it doesn't get called for you on assignment.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

In C++ we have a copy constructor. What is the equivalent in .Net? Would
that
be a clone method?

 

[Nicholas Paldino [.NET/C# MVP]]

Dave,

In comparison to C++, no, there is no such thing. Yes, you can create a
constructor that will take a reference to the same type, but that will not
give you the assignment semantics that copy constructors give you in C++.
You still have to make the call explicitly to the constructor, which is the
point I am trying to make. To C#, it's all the same, and it is not treated
differently, unlike the C++ compiler treats it.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

This puzzles me. First of all, saying "The IClonable interface is the
closest
thing to a copy constructor" implies that there is no copy constructor in
C#,
which of course there is.
So what is the difference between ICloneable and a copy constructor. There
appears to be none, in which case what is the purpose of ICloneable? Ollie
Riches says "usually in my experience the Clone method usually calls the
copy
constructor internally" - so why bother with ICloneable at all if a public
copy constructor would be just as good?
--
Dave

Arne,

The IClonable interface is the closest thing to a copy constructor.
However, you have to manually invoke the Clone method on the IClonable
interface, it doesn't get called for you on assignment.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

In C++ we have a copy constructor. What is the equivalent in .Net?
Would
that
be a clone method?

 

[Joanna Carter [TeamB]]

"Dave" <[email protected]> a écrit dans le message de (e-mail address removed)...

| So what is the difference between ICloneable and a copy constructor. There
| appears to be none, in which case what is the purpose of ICloneable? Ollie
| Riches says "usually in my experience the Clone method usually calls the
copy
| constructor internally" - so why bother with ICloneable at all if a public
| copy constructor would be just as good?

A copy constructor allows you to get a strictly typed instance of the class,
whereas ICloneable retirns an Object reference which has to be cast to the
correct type.

Of course, you can use the copy constructor in the Clone() method to save
duplicate code.

public class Thing
{
private string name;

public Thing() { }

public Thing(Thing other)
{
name = other.name;
}

object ICloneable.Clone()
{
return new Thing(this);
}
}

There are several classes in various frameworks that expect an object to
support ICloneable; providing a copy constructor is useful for code where
you are the one who is using the class and want control over the type
returned by the copying process.

Joanna

 

[Nick Hounsome]

Most C# objects are of reference type therefore their equivalent in C++ is a
pointer not an object and therefore they could never have the same copy
constructor machinery as C++.

Obviously this does not apply to value types.

Given the above, the Clone() method would still not be like a copy
constructor because it is a virtual method which allows you to copy an
object without knowing its type - this is not possible with a constructor.

Dave,

In comparison to C++, no, there is no such thing. Yes, you can create
a constructor that will take a reference to the same type, but that will
not give you the assignment semantics that copy constructors give you in
C++. You still have to make the call explicitly to the constructor, which
is the point I am trying to make. To C#, it's all the same, and it is not
treated differently, unlike the C++ compiler treats it.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

This puzzles me. First of all, saying "The IClonable interface is the
closest
thing to a copy constructor" implies that there is no copy constructor in
C#,
which of course there is.
So what is the difference between ICloneable and a copy constructor.
There
appears to be none, in which case what is the purpose of ICloneable?
Ollie
Riches says "usually in my experience the Clone method usually calls the
copy
constructor internally" - so why bother with ICloneable at all if a
public
copy constructor would be just as good?
--
Dave

Arne,

The IClonable interface is the closest thing to a copy constructor.
However, you have to manually invoke the Clone method on the IClonable
interface, it doesn't get called for you on assignment.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

In C++ we have a copy constructor. What is the equivalent in .Net?
Would
that
be a clone method?

 

[Guest]

OK I see what you mean. Nevertheless my question still stands - given that
you have to either *explicitly* call the copy constructor, or *explicitly*
call the Clone method, is there any advantage of one over the other?
The temptation to override the assignment operator in all my classes to get
back to a C++ way of life is almost overwhelming.
--
Dave

Dave,

In comparison to C++, no, there is no such thing. Yes, you can create a
constructor that will take a reference to the same type, but that will not
give you the assignment semantics that copy constructors give you in C++.
You still have to make the call explicitly to the constructor, which is the
point I am trying to make. To C#, it's all the same, and it is not treated
differently, unlike the C++ compiler treats it.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

This puzzles me. First of all, saying "The IClonable interface is the
closest
thing to a copy constructor" implies that there is no copy constructor in
C#,
which of course there is.
So what is the difference between ICloneable and a copy constructor. There
appears to be none, in which case what is the purpose of ICloneable? Ollie
Riches says "usually in my experience the Clone method usually calls the
copy
constructor internally" - so why bother with ICloneable at all if a public
copy constructor would be just as good?
--
Dave

Arne,

The IClonable interface is the closest thing to a copy constructor.
However, you have to manually invoke the Clone method on the IClonable
interface, it doesn't get called for you on assignment.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

In C++ we have a copy constructor. What is the equivalent in .Net?
Would
that
be a clone method?

 

[Nicholas Paldino [.NET/C# MVP]]

Dave,

In this case, the only advantage you have with a "copy" constructor is
that you have type checking at compile type, whereas with IClonable, you
have to use a cast, which blows up in your face if the cast fails.

I prefer having the type checking, personally, and would use that over
IClonable.

What I ^really^ would have liked would have been to see IClonable<T>,
but alas, it is not in the framework.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

OK I see what you mean. Nevertheless my question still stands - given that
you have to either *explicitly* call the copy constructor, or *explicitly*
call the Clone method, is there any advantage of one over the other?
The temptation to override the assignment operator in all my classes to
get
back to a C++ way of life is almost overwhelming.
--
Dave

Dave,

In comparison to C++, no, there is no such thing. Yes, you can
create a
constructor that will take a reference to the same type, but that will
not
give you the assignment semantics that copy constructors give you in C++.
You still have to make the call explicitly to the constructor, which is
the
point I am trying to make. To C#, it's all the same, and it is not
treated
differently, unlike the C++ compiler treats it.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

This puzzles me. First of all, saying "The IClonable interface is the
closest
thing to a copy constructor" implies that there is no copy constructor
in
C#,
which of course there is.
So what is the difference between ICloneable and a copy constructor.
There
appears to be none, in which case what is the purpose of ICloneable?
Ollie
Riches says "usually in my experience the Clone method usually calls
the
copy
constructor internally" - so why bother with ICloneable at all if a
public
copy constructor would be just as good?
--
Dave


:

Arne,

The IClonable interface is the closest thing to a copy
constructor.
However, you have to manually invoke the Clone method on the IClonable
interface, it doesn't get called for you on assignment.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

In C++ we have a copy constructor. What is the equivalent in .Net?
Would
that
be a clone method?

 

[Nick Hounsome]

ICloneable<T> wouldn't give you anything.
If you know an object is ICloneable and a T then it follows that it must be
safe to cast Clone() to T.

[I just realized that it would save you the boxing]

NB I always implement ICloneable.Clone explicitly and provide an additional
strongly typed Clone method for the case where you would use a copy
constructor in C++. IMHO this is a nobrainer.

Dave,

In this case, the only advantage you have with a "copy" constructor is
that you have type checking at compile type, whereas with IClonable, you
have to use a cast, which blows up in your face if the cast fails.

I prefer having the type checking, personally, and would use that over
IClonable.

What I ^really^ would have liked would have been to see IClonable<T>,
but alas, it is not in the framework.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

OK I see what you mean. Nevertheless my question still stands - given
that
you have to either *explicitly* call the copy constructor, or
*explicitly*
call the Clone method, is there any advantage of one over the other?
The temptation to override the assignment operator in all my classes to
get
back to a C++ way of life is almost overwhelming.
--
Dave

Dave,

In comparison to C++, no, there is no such thing. Yes, you can
create a
constructor that will take a reference to the same type, but that will
not
give you the assignment semantics that copy constructors give you in
C++.
You still have to make the call explicitly to the constructor, which is
the
point I am trying to make. To C#, it's all the same, and it is not
treated
differently, unlike the C++ compiler treats it.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

This puzzles me. First of all, saying "The IClonable interface is the
closest
thing to a copy constructor" implies that there is no copy constructor
in
C#,
which of course there is.
So what is the difference between ICloneable and a copy constructor.
There
appears to be none, in which case what is the purpose of ICloneable?
Ollie
Riches says "usually in my experience the Clone method usually calls
the
copy
constructor internally" - so why bother with ICloneable at all if a
public
copy constructor would be just as good?
--
Dave


:

Arne,

The IClonable interface is the closest thing to a copy
constructor.
However, you have to manually invoke the Clone method on the
IClonable
interface, it doesn't get called for you on assignment.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

In C++ we have a copy constructor. What is the equivalent in .Net?
Would
that
be a clone method?

 

[Nicholas Paldino [.NET/C# MVP]]

Nick,

See inline:

ICloneable<T> wouldn't give you anything.
If you know an object is ICloneable and a T then it follows that it must
be safe to cast Clone() to T.

Not true. If I had ICloneable<T> then the Clone method would return a
string, not an object, and the compiler can verify that my assignments are
valid. For example, in .NET 1.1 and before, you can do this:

string s = "This is a string.";
int i = (int) s.Clone();

And the compiler would not detect it. The error would occur at run
time.

If IClonable was generic, then you would do this (hypothetically):

string s = "This is a string.";
int i = s.Clone();

The compiler would not allow this, because the implicit implementation
of ICloneable<string> would return a string, and the compiler would
recognize that is not a valid assignment.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

[I just realized that it would save you the boxing]

NB I always implement ICloneable.Clone explicitly and provide an
additional strongly typed Clone method for the case where you would use a
copy constructor in C++. IMHO this is a nobrainer.

Dave,

In this case, the only advantage you have with a "copy" constructor is
that you have type checking at compile type, whereas with IClonable, you
have to use a cast, which blows up in your face if the cast fails.

I prefer having the type checking, personally, and would use that over
IClonable.

What I ^really^ would have liked would have been to see IClonable<T>,
but alas, it is not in the framework.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

OK I see what you mean. Nevertheless my question still stands - given
that
you have to either *explicitly* call the copy constructor, or
*explicitly*
call the Clone method, is there any advantage of one over the other?
The temptation to override the assignment operator in all my classes to
get
back to a C++ way of life is almost overwhelming.
--
Dave


:

Dave,

In comparison to C++, no, there is no such thing. Yes, you can
create a
constructor that will take a reference to the same type, but that will
not
give you the assignment semantics that copy constructors give you in
C++.
You still have to make the call explicitly to the constructor, which is
the
point I am trying to make. To C#, it's all the same, and it is not
treated
differently, unlike the C++ compiler treats it.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

This puzzles me. First of all, saying "The IClonable interface is the
closest
thing to a copy constructor" implies that there is no copy
constructor in
C#,
which of course there is.
So what is the difference between ICloneable and a copy constructor.
There
appears to be none, in which case what is the purpose of ICloneable?
Ollie
Riches says "usually in my experience the Clone method usually calls
the
copy
constructor internally" - so why bother with ICloneable at all if a
public
copy constructor would be just as good?
--
Dave


:

Arne,

The IClonable interface is the closest thing to a copy
constructor.
However, you have to manually invoke the Clone method on the
IClonable
interface, it doesn't get called for you on assignment.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

In C++ we have a copy constructor. What is the equivalent in .Net?
Would
that
be a clone method?

 

[Bruce Wood]

Now, I'm no generics guru, but then that's why I thought to ask this
question: so I can learn.

Correct me if I'm wrong, but if the Framework offered an ICloneable<T>
interface, then how would you write code that required nothing more
than that an object be cloneable? For example, currently I can write
this:

public object MyFunction(ICloneable abc) { ... }

and what that means is that abc must have (at least) a Clone() method.
However, if we introduce ICloneable<T>, and I declare this:

public class MyClass : ICloneable<MyClass>
{
...
public MyClass Clone() { ... }
}

and then try to do this:

MyClass abc = new MyClass();
MyFunction(abc);

won't the compiler give me an error, saying that "abc" does not
implement ICloneable... because it doesn't: it implements
ICloneable<MyClass>, which is not the same thing. If I then try to say:

public MyClass : ICloneable<MyClass>, ICloneable
{
}

then I end up with problems of ambiguous reference, because when I say:

MyClass def = abc.Clone();

which method am I calling... the one that returns a MyClass
(ICloneable<MyClass>) or the one that returns an object (ICloneable)?

I'm sure that I'm just confused about this... could someone kindly set
me straight?

 

[James Curran]

OK I see what you mean. Nevertheless my question still stands - given that
you have to either *explicitly* call the copy constructor, or *explicitly*
call the Clone method, is there any advantage of one over the other?

OK, To explain: In C++

MyClass a; // eq to = MyClass();
MyClass b = a; // eq to = MyClass(a);

a & b are two distinct objects, changing one does not change the other.

In C#
MyClass a = new MyClass();
MyClass b = a;

a & b now reference the same object. Changing one WILL affect the
other.

To get what you want in C#:

MyClass a = new MyClass();
MyClass b = a.Clone()

Now, a & b are two distinct objects, changing one does not change the
other. However, you will have write a Clone()

Alternately, we could do this like:
MyClass a = new MyClass();
MyClass b = new MyClass(a);

HOWEVER, that ctor is NOT generated automatically, as it is in C++.

The temptation to override the assignment operator in all my classes to get
back to a C++ way of life is almost overwhelming.

Do NOT (!!!) do that. EVERY C# programmer that will ever use your code
in the future will curse you for it..

If you want to use C++, then use C++.

If you're going to use C#, then learn it's idioms.

--
Truth,
James Curran
[erstwhile VC++ MVP]

Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com

 

[Daniel O'Connell [C# MVP]]

Now, I'm no generics guru, but then that's why I thought to ask this
question: so I can learn.

Correct me if I'm wrong, but if the Framework offered an ICloneable<T>
interface, then how would you write code that required nothing more
than that an object be cloneable? For example, currently I can write
this:

public object MyFunction(ICloneable abc) { ... }

and what that means is that abc must have (at least) a Clone() method.
However, if we introduce ICloneable<T>, and I declare this:

public class MyClass : ICloneable<MyClass>
{
...
public MyClass Clone() { ... }
}

and then try to do this:

MyClass abc = new MyClass();
MyFunction(abc);

won't the compiler give me an error, saying that "abc" does not
implement ICloneable... because it doesn't: it implements
ICloneable<MyClass>, which is not the same thing. If I then try to say:

Yes, it will. Although there are workarounds(such as having IClonable<T>
derive from IClonable, which isn't pretty.) Personaly I'd have written
MyFUnction as:

public void MyFunction<T>(IClonable<T> abc);

which will work(although I havn't checked if type inferencing is smart
enough to find T in that mess, it should be but I'm not sure.)

public MyClass : ICloneable<MyClass>, ICloneable
{
}

then I end up with problems of ambiguous reference, because when I say:

MyClass def = abc.Clone();

which method am I calling... the one that returns a MyClass
(ICloneable<MyClass>) or the one that returns an object (ICloneable)?

Since your type there is ICloneable, it would be the one that returns an
object. You'd probably implement ICloneable explicity like you would for any
other interface, but since the type is ICloneable you'd get that
implementation, quite in line with how interfaces work
elsewhere(IEnumerable<T> & IEnumerable are good examples, they do this exact
thing.)