string comparison with ==

[Peter Kirk]

Hi

I am looking at some code which in many places performs string comparison
using == instead of Equals.

Am I right in assuming that this will in fact work "as expected" when it is
strings involved? By "as expected" I mean that as long as the strings are
instantiated using string literals, then == and Equals are the same.

string s1 = "xxx";
string s2 = "xxx";

if (s1 == s2)
{
}

if (s1.Equals(s2))
{
}

Peter

[Tom Porterfield]

Peter Kirk wrote:

Hi

I am looking at some code which in many places performs string comparison
using == instead of Equals.

Am I right in assuming that this will in fact work "as expected" when it is
strings involved? By "as expected" I mean that as long as the strings are
instantiated using string literals, then == and Equals are the same.

string s1 = "xxx";
string s2 = "xxx";

if (s1 == s2)
{
}

if (s1.Equals(s2))
{
}

Yes, they do the same thing. I believe the equal operator on string just
calls .Equals.
--
Tom Porterfield

[Jon Skeet [C# MVP]]

Peter Kirk <[e-mail]> wrote:

I am looking at some code which in many places performs string comparison
using == instead of Equals.

Am I right in assuming that this will in fact work "as expected" when it is
strings involved? By "as expected" I mean that as long as the strings are
instantiated using string literals, then == and Equals are the same.

It will work as expected whether or not they're string literals, so
long as both sides of the expression are strings (to the compiler) -
String overloads the == operator to call String.Equals(x,y).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Stephen Ahn]

"Peter Kirk" <[e-mail]> wrote in message
news:uB*************@TK2MSFTNGP15.phx.gbl...

Hi

I am looking at some code which in many places performs string comparison
using == instead of Equals.

To add to the other posts, here's some additional info from
what I've seen.

Example code :

private void button10_Click(object sender, System.EventArgs e)
{
string s1 = "hello"; // XXX
string s2 = string.Copy(s1);

if (s1 == s2)
MessageBox.Show("Test 1 : was equal");
else
MessageBox.Show("Test 1 : not equal");

object s1obj = s1;

if (s1obj == "hello") // YYY
MessageBox.Show("Test 2 : was equal");
else
MessageBox.Show("Test 2 : not equal");

if (s1obj == s2) // ZZZ
MessageBox.Show("Test 3 : was equal");
else
MessageBox.Show("Test 3 : not equal");
}
When run, this code displays :

"Test 1 : was equal"
"Test 2 : was equal"
"Test 3 : not equal"
The string class overloads the following "==" operator :

public static bool operator ==(string a, string b)
, so that when you use the "==" operator on two strings, the actual contents
of
the string are compared, and not their references. That is why test 1
passes.

In case of test 2, the overloaded "==" operator defined in the string class
is not invoked, because the s1obj variable is of type "object".
This results in a reference comparison. This is also what happens in test 3.

However, the results of test 2 and test 3 are different.
This is because in test 2, we got lucky, since the lteral constant : "hello"
on line marked "XXX" is the same (i.e. the same reference) as the literal
constant "hello" marked on line YYY. (I guess this is probably due to
dotnet realizing that the strings hold the same contents, so just make
them point to the one copy). (You could confirm this by evaluating
something like : object.ReferenceEquals(s1obj, "hello"), which
returns true.)
Even though test 2 worked, it is not really a good idea to use code
like this. (As shown by test 3).

The C# compiler even gives you a warning about lines YYY and ZZZ :

==

form1.cs(334,8): warning CS0252: Possible unintended reference
comparison; to get a value comparison, cast the left
hand side to type 'string'

==

[Stephen Ahn]

Sorry, to clarify -:

using "==" when both sides are string variables, as in test 1,
is fine, but not a good idea (IMO) in cases such as test2 or test3.

"Stephen Ahn" <noaddress_at_noaddress.com> wrote in message
news:uZ**************@TK2MSFTNGP10.phx.gbl...

Even though test 2 worked, it is not really a good idea to use code
like this. (As shown by test 3).