copy ctore, assignment operator and Clone() - dang!

[Steve]

I can't find a straight answer on what to use? I need a deep copy, so I
implemented IConeable and the Clone() method. However, I'm not sure I did
it correct. Is it suposed to be an allocation of a new object, then the
assignment of each member? Is that all or is there something else I need to
do?

Here is my code
<code>
public Object Clone()
{
BOLDeviceProtoc ol newObject = new BOLDeviceProtoc ol();

newObject.m_cus tom = this.m_custom;
newObject.m_dal = this.m_dal;
newObject.m_dev iceProtocolID = this.m_devicePr otocolID;
newObject.m_dev iceSettingsID = this.m_deviceSe ttingsID;
newObject.m_dur ation = this.m_duration ;
newObject.m_ena bled = this.m_enabled;
newObject.m_isD irty = this.m_isDirty;
newObject.m_pro tocolID = this.m_protocol ID;
newObject.m_pro tocolName = this.m_protocol Name;
newObject.m_pro tocolNumber = this.m_protocol Number;
newObject.m_seg ments = new BOLProtocolSegm entList();
foreach(BOLProt ocolSegment segment in this.m_segments )
{
newObject.m_seg ments.Add(segme nt);
}

return newObject;
}
</code>

How do I know that m_segments.Add( ) is creating a deep copy of segment?

I'm just looking for a little verification.

Thanks,
Steve

[Bruce Wood]

That depends upon the implementation of BOLProtocolSegm entList. If
BOLProtocolSegm entList.Add is defined to clone the object before adding
the clone to the list, then yes, your Clone() method is cloning the
segments because it's calling the Add() method, which is designed to
clone before it adds.

However, that's a really bad design.

More likely (and more correctly), the Add method of
BOLProtocolSegm entList should not clone before it adds. It should just
add whatever it's given to the list. In that case, you have to do the
Clone yourself, if you want a deep copy:

newObject.m_seg ments.Add(segme nt.Clone());

and yes, this means that BOLProtocolSegm ent must implement ICloneable,
too.

[sklett]

"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** *************@g 43g2000cwa.goog legroups.com...

That depends upon the implementation of BOLProtocolSegm entList. If
BOLProtocolSegm entList.Add is defined to clone the object before adding
the clone to the list, then yes, your Clone() method is cloning the
segments because it's calling the Add() method, which is designed to
clone before it adds.

However, that's a really bad design.

More likely (and more correctly), the Add method of
BOLProtocolSegm entList should not clone before it adds. It should just
add whatever it's given to the list. In that case, you have to do the
Clone yourself, if you want a deep copy:

newObject.m_seg ments.Add(segme nt.Clone());

and yes, this means that BOLProtocolSegm ent must implement ICloneable,
too.

Thank you for the response, Bruce. It's taking a little time to get my head
around the details for reference/value types. It was really nice and easy
when I didn't care, but now that I need to worry about it, it's a little
confusing.

What I have done for some of my objects is implement Clone() like this:
<code>
public Object Clone()
{
BOLCustomerConf iguration newConfig =
(BOLCustomerCon figuration)this .MemberwiseClon e();

// deep copy reference types
newConfig.m_dal = new DALMSAccess();
newConfig.m_des cription = (string)this.m_ description.Clo ne();
newConfig.m_nam e = (string)this.m_ name.Clone();
newConfig.m_dev iceSettings = new BOLDeviceSettin gsList();
foreach(BOLDevi ceSettings item in this.m_deviceSe ttings)
{
newConfig.m_dev iceSettings.Add ( item );
}

return newConfig;
}
</code>

That seems correct to me and so far, it seems to behave correctly. String,
being an array and therefore a reference type needs a deep copy, correct?

Thanks again for the post,
Steve

[Bruce Wood]

No, string does not need a deep copy because string is a bit of an
oddity: it's immutable. That means that you can never change the
contents of a string, only generate a new string based on an existing
string. So, once you say:

string s = "Hello There!";
string a = s;

You can be guaranteed that the string that "a" refers to will always
say "Hello There!" unless you change "a". If you do this:

s = s.Substring(0, 5);

Then all you've done is assign "s" to refer to a different string that
contains "Hello". "a" will continue to refer to the original string,
which says "Hello There!".

So, yes, strings are reference types, but they are special reference
types that you can trust never to change.

[Steve]

Interesting, so for string, in my Clone() method I would simple need to do:
string newString = new string.empty();
newString = oldString;

Since there is not a constructor that will take string, I guess this is the
cleanest way?
"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ g43g2000cwa.goo glegroups.com.. .

No, string does not need a deep copy because string is a bit of an
oddity: it's immutable. That means that you can never change the
contents of a string, only generate a new string based on an existing
string. So, once you say:

string s = "Hello There!";
string a = s;

You can be guaranteed that the string that "a" refers to will always
say "Hello There!" unless you change "a". If you do this:

s = s.Substring(0, 5);

Then all you've done is assign "s" to refer to a different string that
contains "Hello". "a" will continue to refer to the original string,
which says "Hello There!".

So, yes, strings are reference types, but they are special reference
types that you can trust never to change.

[Bruce Wood]

Not even. All you need to do is this:

<code>
newConfig.m_des cription = this.m_descript ion;
newConfig.m_nam e = this.m_name;
</code>

Since strings are immutable, you are guaranteed that the strings that
newConfig.m_des cription and newConfig.m_nam e refer to will never
change. The only way to "change them" is to point m_description and
m_name to some other strings.

[Steve]

Oh wow, this is pointing out a much bigger issue I'm having then ;)
I had weird behavior this morning where;
SettingsObject A.Name = "Default";
// create a copy of SettingsObject, B
B.Name = "Test";

was changing both values. I didn't check too into it, I just assumed they
were reference types and then changed the Clone() method, but based on your
post (and the test I just did), this would indicate that something very
different is happening (Like I didn't really create a copy of SettingsObject
but perhaps a reference)

OK, I'm done now, thanks for your help, I get it.


"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ g43g2000cwa.goo glegroups.com.. .

Not even. All you need to do is this:

<code>
newConfig.m_des cription = this.m_descript ion;
newConfig.m_nam e = this.m_name;
</code>

Since strings are immutable, you are guaranteed that the strings that
newConfig.m_des cription and newConfig.m_nam e refer to will never
change. The only way to "change them" is to point m_description and
m_name to some other strings.