How to copy an object instead of geting the reference

[DogEye]

In the C# , I want to change the object only after the user click the
"Submit" button , so I first new an object and use the "=" to get the object
in memory , I found that the operation "=" only get a reference to the
target object which I want to copy , how can I do copy it ?

 

[Sergei]

In the C# , I want to change the object only after the user click the
"Submit" button , so I first new an object and use the "=" to get the object
in memory , I found that the operation "=" only get a reference to the
target object which I want to copy , how can I do copy it ?

If the object type supports copying (cloning) it implements the ICloneable
interface.

// begin
String s1 = "Original string";
String s2 = (String) s1.Clone(); // this must be a copy of the original string
s1 = "Another string";
Console.WriteLine(s1);
Console.WriteLine(s2);
// end

Sergei

 

[Michael Voss]

In the C# , I want to change the object only after the user click the
"Submit" button , so I first new an object and use the "=" to get the object
in memory , I found that the operation "=" only get a reference to the
target object which I want to copy , how can I do copy it ?

Why do you want to copy the object you just created ? So you'd create a new
object and keep a copy of that in memory ? What are you going to do with the
original objcet ?

 

[Mark Broadbent]

1. This example is complete nonsense, since a string is a specialised object
and is immutable and therefore just by "referencing" another instance you
are effectively making a copy. See thus...
string s1 = "two";
string s2 = s1;
s1 = "one";
System.Diagnostics.Debug.WriteLine(string.Format("s1 {0}, s2
{1}",s1,s2));

2. DogEye, Although in essence Sergei's technique for copying an object is
correct, please note that available to you are Copy and Clone methods to
make shallow and deep copies. Unfortunately (I seem to remember) there is a
little inconsistancy of their actions in the Framework - so for more complex
objects you should make sure to check the documentation to see what
functionality you are getting before assuming it.

Br,

Mark.

 

[Howard Swope]

In C# there are reference types and value types. Classes are reference types
and structs as well as basic types are value types.

If you want to copy a class, you can't use the assignment operator. You must
use some other method. Many classes will implement mechanisms to perform
this action. The framework defines an interface ICloneable that is
implemented by many framework classes. However, ICloneable doesn't dictate
weather a deep or shallow copy is made. You will have to look to the
documentation for a particular class to see for sure. A deep copy makes full
copies of all state information including other objects that are members of
the class being copied. In a shallow copy all state is copied but references
to member objects are maintained.

 

[Rico]

1. This example is complete nonsense, since a string is a specialised
object and is immutable and therefore just by "referencing" another
instance you are effectively making a copy. See thus...
string s1 = "two";
string s2 = s1;
s1 = "one";
System.Diagnostics.Debug.WriteLine(string.Format("s1 {0}, s2
{1}",s1,s2));

Does your example support what you said that 's2 = s1' causes a copy of s1
to be made?
As in, new memory allocated, content of s1 copied over to new memory,
address of new memory written in s2 ?

How do we know that s2 isn't still pointing to the memory region initially
allocated for s1 ?

I would think that only knowing the addresses stored in s1 and s2 would
prove what 'referencing' does and what Clone() does.

Rico.

 

[Jon Skeet [C# MVP]]

Does your example support what you said that 's2 = s1' causes a copy of s1
to be made?

No - in fact a copy isn't being made, but because strings are immutable
it *sort* of looks like it is. Personally I don't like talking about
strings as if they were special - they have *some* special handling
(for literals, basically) but there aren't many things about them which
are different to any other immutable class.

As in, new memory allocated, content of s1 copied over to new memory,
address of new memory written in s2 ?
Nope.

How do we know that s2 isn't still pointing to the memory region initially
allocated for s1 ?

It is, in fact.

I would think that only knowing the addresses stored in s1 and s2 would
prove what 'referencing' does and what Clone() does.

In fact, using object.ReferenceEquals you can tell that string.Clone()
just returns "this":

using System;

public class Test
{
static void Main()
{
string x = "hello";
string y = (string)x.Clone();
Console.WriteLine (object.ReferenceEquals(x, y));
}
}

 

[Mark Broadbent]

Really not sure what you are trying to say?
As my example demonstrates Sergei's use of the string type in this scenario
is not valid. As I said in my post since string is immutable, it is
impossible for one string to change the an instance of another string. This
is fact and is pointless debating, so proving that s1 doesnt point to s2 is
not required.
You'll also note that I said "referencing another instance you
are effectively making a copy" in this string scenario. What I mean by
'effectively' is that even *if* s1 did point to s2 at that time of
assignment, the exact moment that a change is made to either s1 or s2 they
would point to different instances due to the immutable rule (as my simple
example shows).
What is happening is not the same as what you say

'As in, new memory allocated, content of s1 copied over to new memory,
address of new memory written in s2 ?'

to put it simply, the value that is referenced by a string variable is
protected from a change from another.

br,

Mark.

 

[Jeff Louie]

Since you ask if the assignment operator makes a copy I am assuming that
you may come from C++. The _key_ concept here is that in C++ objects
have
_value_ semantics so that the assignment operator may make a copy. In
C#,
classes have reference semantics. IMHO, it is best to adjust to the use
of C#
reference semantics and garbage collection. If you want value semantics
and
if you want copy on assignment behaviour then you can use struct in C#.

So to really understand your need, it would be helpful to know why you
need
a copy of the object, rather than just changing the state of the object
using
the reference. Strings are immutable objects, so you cannot change the
state
of a string, but you can create a new string and assign it to an
existing
reference variable. This is done automagically without a call to new.

Regards,
Jeff

 

[Sergei]

1. This example is complete nonsense, since a string is a specialised object
and is immutable

Yes, I shouldn't use the String type in the example
because its Clone() doesn't clone.

Sergei

and therefore just by "referencing" another instance you

 

[Rico]

Really not sure what you are trying to say?

That you are funny?

You'll also note that I said "referencing another instance you
are effectively making a copy" in this string scenario. What I mean by
'effectively' is that even *if* s1 did point to s2 at that time of
assignment, the exact moment that a change is made to either s1 or s2 they
would point to different instances due to the immutable rule (as my simple
example shows).

The mention of "s2 = s1;"
'effectively' making a copy would lead one to think that the subsequent

's1 = "two" ; '

makes the initial object pointed to by s1 eligible for garbage collection,
whereas I should think that it is not because it is being pointed to by s2.

to put it simply, the value that is referenced by a string variable is
protected from a change from another.

I think it's just more confusing to bring up 'effective copies' to
explain that. String is immutable. The content of the object it references
cannot be changed. Period.
What's up with the new school of thought of some need for protection from
"another" ? heh.

Rico.

 

[Mark Broadbent]

Not really sure why you are *still* trying to keep this thread going *but*
this is going to be my last post to it.

-See inline comments

That you are funny?


No.



The mention of "s2 = s1;"
'effectively' making a copy would lead one to think that the subsequent

's1 = "two" ; '

makes the initial object pointed to by s1 eligible for garbage collection,
whereas I should think that it is not because it is being pointed to by
s2.

Yes s2 does point to this instance, examining the machine code or IL shows
this. No, my previous posts were adequate and explanatory.
Also the term "effective" is completely fine in this context. "effective" !=
"actual".

I think it's just more confusing to bring up 'effective copies' to
explain that. String is immutable. The content of the object it references
cannot be changed. Period.

I've already explained the immutable concept.
Also your description "object it references cannot be changed" is incorrect.
The referenced location is not safe from changes by pointers.
My description *is* correct "to put it simply, the value that is referenced
by a string variable is protected from a change from another."

What's up with the new school of thought of some need for protection from
"another" ? heh.

??? Sergei's example was incorrect for this scenario, which he readily
admits.