When should I use == and when should I use Equals?

最新推荐文章于 2024-07-08 09:20:11 发布

转载最新推荐文章于 2024-07-08 09:20:11 发布 · 1.6k 阅读

文章标签：

#equals #types #reference #compiler #exception #object

.Net 专栏收录该内容

8 篇文章

订阅专栏

博客主要探讨了 == 和 Equals 的使用场景。== 是可被类重载的运算符，通常用于比较引用是否指向同一对象；Equals 是虚方法，可被类重写。对于引用类型，多数情况用 Equals 测试相等性；对于值类型，用 == 代码更易读。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

When should I use == and when should I use Equals?

The Equals method is just a virtual one defined in System.Object, and overridden by whichever classes choose to do so. The == operator is an operator which can be overloaded by classes, but which usually has identity behaviour.

For reference types where == has not been overloaded, it compares whether two references refer to the same object - which is exactly what the implementation of Equals does in System.Object.

Value types do not provide an overload for == by default. However, most of the value types provided by the framework provide their own overload. The default implementation of Equals for a value type is provided by ValueType, and uses reflection to make the comparison, which makes it significantly slower than a type-specific implementation normally would be. This implementation also calls Equals on pairs of references within the two values being compared.

However, the main difference between the two types of comparison in normal use (where you're unlikely to be defining your own value types very often) is polymorphism. Operators are overloaded, not overridden, which means that unless the compiler knows to call the more specific version, it'll just call the identity version.

So, when should you use which operator? My rule of thumb is that for almost all reference types, use Equals when you want to test equality rather than reference identity. The exception is for strings - comparing strings with == does make things an awful lot simpler and more readable but you need to remember that both sides of the operator must be expressions of type string in order to get the comparison to work properly.

For value types, I'd normally use == for easier-to-read code. Things would get tricky if a value type provided an overload for == which acted differently to Equals, but I'd consider such a type very badly designed to start with.