我在silverlight应用程序中有一个比较2个字符串的条件，由于某种原因，当我使用==时，它返回false而. equals()返回true。
代码如下:
if (((ListBoxItem)lstBaseMenu.SelectedItem).Content.Equals("Energy Attack"))
{
// Execute code
}
if (((ListBoxItem)lstBaseMenu.SelectedItem).Content == "Energy Attack")
{
// Execute code
}
你知道为什么会这样吗?
当前回答
注意，在c#中有两种不同类型的等式
1-值相等(对于int, DateTime和struct等值类型)
2-引用平等(对象)
有两个基本的标准协议来实现相等性检查。
1- ==和!=运算符。
2- virtual Equals方法。
==和!=是静态解析的，这意味着c#将在编译时决定哪种类型将执行比较。
例如值类型
int x = 50;
int y = 50;
Console.WriteLine (x == y); // True
但是对于参考类型
object x = 50;
object y = 50;
Console.WriteLine (x == y); // False
Equals()最初在运行时根据操作数的实际类型解析。
例如，在下面的例子中，在运行时，将决定Equals()将应用于int值，结果为真。
object x = 5;
object y = 5;
Console.WriteLine (x.Equals (y)); // True
但是，对于引用类型，它将使用引用相等性检查。
MyObject x = new MyObject();
MyObject y = x;
Console.WriteLine (x.Equals (y)); // True
注意Equals()对struct使用结构比较，这意味着它对struct的每个字段调用Equals。
其他回答
==和. equals都依赖于实际类型中定义的行为和调用位置上的实际类型。两者都只是方法/操作符，可以在任何类型上重写，并给定作者希望的任何行为。根据我的经验，我发现人们在对象上实现. equals却忽略了operator ==是很常见的。这意味着. equals将实际测量值是否相等，而==将测量它们是否是相同的引用。
当我处理一个定义不断变化的新类型或编写泛型算法时，我发现最佳实践如下
如果我想在c#中比较引用，我使用Object。直接使用ReferenceEquals(在泛型情况下不需要) 如果我想比较值，我使用EqualityComparer<T>。默认的
在某些情况下，当我觉得==的用法不明确时，我会显式地使用Object。在代码中引用等号以消除歧义。
Eric Lippert最近写了一篇博文，主题是为什么在CLR中有两种相等的方法。值得一读
http://blogs.msdn.com/ericlippert/archive/2009/04/09/double-your-dispatch-double-your-fun.aspx
@BlueMonkMN早前的回答还有另一个层面。额外的维度是，@Drahcir的标题问题的答案也取决于我们如何得到字符串值。说明:
string s1 = "test";
string s2 = "test";
string s3 = "test1".Substring(0, 4);
object s4 = s3;
string s5 = "te" + "st";
object s6 = s5;
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s2), s1 == s2, s1.Equals(s2));
Console.WriteLine("\n Case1 - A method changes the value:");
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s3), s1 == s3, s1.Equals(s3));
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s4), s1 == s4, s1.Equals(s4));
Console.WriteLine("\n Case2 - Having only literals allows to arrive at a literal:");
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s5), s1 == s5, s1.Equals(s5));
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s6), s1 == s6, s1.Equals(s6));
输出结果为:
True True True
Case1 - A method changes the value:
False True True
False False True
Case2 - Having only literals allows to arrive at a literal:
True True True
True True True
这是由于值相等(equal方法)和引用相等(==运算符)，因为equal方法检查值，而相同的==检查引用。
==运算符覆盖https://referencesource.microsoft.com/上string类内可用的代码
现在更容易理解了，equal方法也有两个实现一个来自string类本身，一个来自object类。它对性能的影响以及我也运行一些基本的代码，并试图理解基准测试。
我分享下面的结果，如果我错了，请纠正或建议。有3种情况，我对所有情况运行了相同的代码，这就是结果。
情况1:这里我使用的是字符串。相等的方法比较两个字符串和两个字符串有相同的值。string.equals (a, b)
第一次运行:5608195 tick
第二次运行:5529387个刻度
第三次运行:5622569滴答
总蜱数:16760151
情况2:这里我使用的是字符串。Equal()方法(重载的一个)用于比较两个字符串，并且两个字符串具有相同的值。 a.equals (b)
第一次运行:6738583滴答
第二轮:6452927
第三轮:7168897个刻度
总蜱虫= 20360407
情况3:这里我使用==操作符比较2个字符串，两个字符串都有相同的值。 a = =
第一次运行:6652151滴答
第二次运行:7514300个tick
第三轮:7634606滴答
总蜱虫= 21801057
class Program
{
private static int count;
static string a = "abcdef";
static string b = "abcdef";
static void Main(string[] args)
{
for (int j = 1; j <= 3; j++)
{
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 1; i <= 1000; i++)
{
checkString();
}
sw.Stop();
Console.WriteLine(sw.ElapsedTicks);
}
Console.ReadLine();
}
public static void checkString()
{
for (int i = 1; i <= 100000; i++)
{
if (a==b)
count++;
}
}
}
注意，在c#中有两种不同类型的等式
1-值相等(对于int, DateTime和struct等值类型)
2-引用平等(对象)
有两个基本的标准协议来实现相等性检查。
1- ==和!=运算符。
2- virtual Equals方法。
==和!=是静态解析的，这意味着c#将在编译时决定哪种类型将执行比较。
例如值类型
int x = 50;
int y = 50;
Console.WriteLine (x == y); // True
但是对于参考类型
object x = 50;
object y = 50;
Console.WriteLine (x == y); // False
Equals()最初在运行时根据操作数的实际类型解析。
例如，在下面的例子中，在运行时，将决定Equals()将应用于int值，结果为真。
object x = 5;
object y = 5;
Console.WriteLine (x.Equals (y)); // True
但是，对于引用类型，它将使用引用相等性检查。
MyObject x = new MyObject();
MyObject y = x;
Console.WriteLine (x.Equals (y)); // True
注意Equals()对struct使用结构比较，这意味着它对struct的每个字段调用Equals。
I am a bit confused here. If the runtime type of Content is of type string, then both == and Equals should return true. However, since this does not appear to be the case, then runtime type of Content is not string and calling Equals on it is doing a referential equality and this explains why Equals("Energy Attack") fails. However, in the second case, the decision as to which overloaded == static operator should be called is made at compile time and this decision appears to be ==(string,string). this suggests to me that Content provides an implicit conversion to string.
