System.Object.ReferenceEquals method

[Kiran A K]

hi,
consider the following piece of code:
string s1 = "kiran";

string s3 = s1.Clone() as string;

Console.WriteLi ne(System.Objec t.ReferenceEqua ls(s1, s3));

The above piece of code gave me true while i was expecting false.

s3 is a clone of s1. so s1 and s3 should be separate objects right?

as a result, one would expect "ReferenceEqual s" to return false...

can anyone pls explain what exactly is happening?

regards,

kiran

[Sayed Ibrahim Hashimi]

RE: System.Object.R eferenceEquals method

This is exactly the expected behavior! Have a look at the String.Clone()
documentation at
http://msdn2.microsoft.com/en-us/lib...ing.clone.aspx
It states that the String.Clone() method "Returns a reference to this
instance of String"

Sayed Ibrahim Hashimi

https://www.sedodream.com

"Kiran A K" wrote:
[color=blue]
> hi,
> consider the following piece of code:
> string s1 = "kiran";
>
> string s3 = s1.Clone() as string;
>
> Console.WriteLi ne(System.Objec t.ReferenceEqua ls(s1, s3));
>
> The above piece of code gave me true while i was expecting false.
>
> s3 is a clone of s1. so s1 and s3 should be separate objects right?
>
> as a result, one would expect "ReferenceEqual s" to return false...
>
> can anyone pls explain what exactly is happening?
>
> regards,
>
> kiran
>
>
>[/color]

[Stoitcho Goutsev \(100\)]

Re: System.Object.R eferenceEquals method

Kiran A K,

I suggest reading some information on string interning. If the string is
interned whenever you try to get a reference to the string it will always
return the same reference.


--

Stoitcho Goutsev (100)

"Kiran A K" <kiran_k@trigen t.com> wrote in message
news:e%23JcfuuK GHA.2828@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> hi,
> consider the following piece of code:
> string s1 = "kiran";
>
> string s3 = s1.Clone() as string;
>
> Console.WriteLi ne(System.Objec t.ReferenceEqua ls(s1, s3));
>
> The above piece of code gave me true while i was expecting false.
>
> s3 is a clone of s1. so s1 and s3 should be separate objects right?
>
> as a result, one would expect "ReferenceEqual s" to return false...
>
> can anyone pls explain what exactly is happening?
>
> regards,
>
> kiran
>
>[/color]

[Jon Skeet [C# MVP]]

Re: System.Object.R eferenceEquals method

Stoitcho Goutsev (100) wrote:[color=blue]
> I suggest reading some information on string interning. If the string is
> interned whenever you try to get a reference to the string it will always
> return the same reference.[/color]

It's not really anything to do with interning. It's arguable that
String.Clone doesn't properly implement ICloneable.Clon e, which states
that a reference to a *new* object is returned. However, as has been
pointed out, the documentation for String.Clone itself explains what's
going on.

Any immutable class could implement the same behaviour though, without
having any concept of interning.

Jon

[Stoitcho Goutsev \(100\)]

Re: System.Object.R eferenceEquals method

Jon,

Thanks for the clarification.

Frankly I didn't read the docs on this (I should've). I'd expected this
behavior for interned strings and expected the Clone method to return new
copy for not-interned. However you are right that this implemetation could
make sense to any immutable types, even though the name of the method -
Clone, is little bit confusing in this case.


--

Stoitcho Goutsev (100)


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:1139236869 .464128.24820@z 14g2000cwz.goog legroups.com...[color=blue]
> Stoitcho Goutsev (100) wrote:[color=green]
>> I suggest reading some information on string interning. If the string is
>> interned whenever you try to get a reference to the string it will always
>> return the same reference.[/color]
>
> It's not really anything to do with interning. It's arguable that
> String.Clone doesn't properly implement ICloneable.Clon e, which states
> that a reference to a *new* object is returned. However, as has been
> pointed out, the documentation for String.Clone itself explains what's
> going on.
>
> Any immutable class could implement the same behaviour though, without
> having any concept of interning.
>
> Jon
>[/color]