本文阐述C#中相等性比较,其中主要集中在下面两个方面
==和!=运算符,什么时候它们可以用于相等性比较,什么时候它们不适用,如果不使用,那么它们的替代方式是什么?
什么时候,需要自定一个类型的相等性比较逻辑
在阐述相等性比较,以及如何自定义相等性比较逻辑之前,我们首先了解一下值类型比较和引用类型比较
C#中的相等性比较有两种:
默认情况下,
实际上,值类型只能使用值相等(除非值类型进行了装箱操作)。看一个简单的例子(比较两个数字),运行的结果为True
int x = 5, y = 5;Console.WriteLine(x == y);
默认地,引用类型使用引用相等。比如下面的例子:返回False
object x = 5, y = 5;Console.WriteLine(x == y);
如果x和y指向同一个对象,那么将返回True:
object x = 5, y = x;Console.WriteLine(x == y);
下面三个标准用于实现相等性比较:
下面我们来分别阐述
1. ==和!=运算符
使用==和!=的原因是它们是运算符,它们通过静态函数实现相等性比较。因此,当你使用==或!=时,C#在编译时就决定了所比较的类型,而且不会执行任何虚方法(Object.Equals)。这是大家所期望的相等行比较。比如在第一个数字比较的例子中,编译器在编译时就决定了执行==运算的类型是int类型,因为x和y都是int类型。
而第二个例子,编译器决定执行==运算的类型是object类型,因为object是类(引用类型),因此对象的==运算符采取引用相等去比较x和y。那么结果就返回False,这是因为x和y指向堆上不同的对象(被装箱的int)
2. Object.Equals虚方法
为了正确地比较第二个例子中的x和y,我们可以使用Equals虚方法。System.Object中定义了Equals虚方法,它适用于所有类型
object x = 5, y = 5;Console.WriteLine(x.Equals(y));
Equals在程序运行时决定比较的类型--根据对象的实际类型进行比较。在上面的例子中,会调用Int32的Euqals方法,该方法使用值相等进行比较,所以上面的例子返回True。如果x和y是引用类型,那么调用引用相等进行比较;如果x和y是结构类型,那么Equals会调用结构每个成员对应类型的Equals方法进行比较。
看到这里,你可能会想,为什么C#的设计者不把==设计成virtaul,从而使其与Equals一样,以避免上诉缺陷。这是因为:
简而言之,复杂的设计反映了复杂的场景:相等的概念涉及到许多场景。
而Euqals方法,适用于比较两个未知类型的对象,下面的这个方法就适用于比较任何类型的两个对象:
public static bool AreEqual(object obj1, object obj2){ return obj1.Equals(obj2);}
但是,该函数不能处理第一个参数是null的情形,如果第一个函数是null,你会得到NullReferenceException异常。因此我们需要对该函数进行修改:
public static bool AreEqual(object obj1, object obj2){ if (obj1 == null) return obj2 == null; return obj1.Equals(obj2);}
object的静态Equals方法
object类还定义了一个静态Equals方法,它的作用与AreEquals方法一样。
public static bool Equals(Object objA, Object objB){ if (objA==objB) { return true; } if (objA==null || objB==null) { return false; } return objA.Equals(objB);}
这样就可以对编译时不知道类型的null对象进行安全地比较。
object x = 5, y = 5;Console.WriteLine(object.Equals(x, y)); // -> Truex = null;Console.WriteLine(object.Equals(x, y)); // -> Falsey = null;Console.WriteLine(object.Equals(x, y)); // -> TrueConsole.WriteLine(x.Equals(y)); // -> NullReferebceException, because x is null
请注意,当编写Generic类型时,下面的代码将不能通过编译(除非把==或!=运算符替换成Object.Equals方法的调用):
public class Test<T> : IEqualityComparer<T>{ T _value; public void SetValue(T newValue) { // Operator '!=' cannot be applied to operands of type 'T' and 'T' // it should be : if(!object.Equals(newValue, _value)) if (newValue != _value) _value = newValue; }}
object的静态ReferenceEquals方法
有时候,你需要强行比较两个引用是否相等。这个时候,你就需要使用object.ReferenceEquals:
internal class Widget { public string UID { get; set; } public override bool Equals(object obj) { if (obj == null) return this == null; if (!(obj is Widget)) return false; Widget w = obj as Widget; return this.UID == w.UID; } public override int GetHashCode() { return this.UID.GetHashCode(); } public static bool operator == (Widget w1, Widget w2) { return w1.Equals(w2); } public static bool operator !=(Widget w1, Widget w2) { return !w1.Equals(w2); }}static void Main(string[] args){ Widget w1 = new Widget(); Widget w2 = new Widget(); Console.WriteLine(w1==w2); // -> True Console.WriteLine(w1.Equals(w2)); // -> True Console.WriteLine(object.ReferenceEquals(w1, w2)); // -> False Console.ReadLine();}Basic ReferenceEquals
之所以调用ReferenceEquals方法,这是因为自定义类Widget重写了object类的虚方法Equals;此外,该类还重写了操作符==和!=,因此执行==时操作也返回True。所以,调用ReferenceEquals可以确保返回引用是否相等。
3. IEquatable<T>接口
调用object.Equals方法实际上对进行比较的值类型进行了装箱操作。在对性能有较高要求的场景,那么就不适合使用这种方式。从C#2.0开始,通过引入IEquatable<T>接口来解决这个问题
public interface IEquatable<T>{ bool Equals(T other);}
当实现IEquatable接口之口,调用接口方法就等同于调用objet的虚方法Equals,但是接口方法执行地更快(不需要类型转换)。大多数.NET基本类型都实现了IEquatable<T>接口,你还可以为Generic类型添加IEquatable<T>限制
internal class Test<T> where T : IEquatable<T>{ public bool IsEqual(T t1, T t2) { return t1.Equals(t2); }}
如果,我们移除IEquatable<T>限制,Test<T>类仍可以通过编译,但是t1.Equals(t2)将使用object.Equals方法。
4. 当Equals结果与==的结果不一致
在前面的内容中,我们已经提到有时候,==或equals适用于不同的场景。比如:
double x = double.NaN;Console.WriteLine(x == x); // FalseConsole.WriteLine(x.Equals(x)); // True
这是因为double类型的==运算符强制NaN不等于其他任何值,即使另外一个NaN。从数学的角度来讲,两个确实不相等。而Equals方法,因为具有对称性,所以x.Equals(x)总返回True。
集合与字典正是依赖于Equals的对称性,否则就不能找到已经保存在集合或字典中的元素。
对于值类型而言,Equals和==很少出现不同的相等性。而在引用类型中,则比较常见。一般地,引用类型的创建者重写Equals方法执行值相等比较,而保留==执行引用相等比较。比如StringBuilder类就是这样的:
StringBuilder buffer1 = new StringBuilder("123");StringBuilder buffer2 = new StringBuilder("123");Console.WriteLine(buffer1 == buffer2); // FalseConsole.WriteLine(buffer1.Equals(buffer2)); // True
回顾一下默认的比较行为
进一步,
有时候,在创建类型时,需要重写上述行为,一般在下面两种情形下需要重写:
1)更改相等的意义
当默认的==和Equals不适用(不符合自然规则,或悖离了使用者的期望)于自定义类型时,就需要更改相等的意义。比如DateTimeOffset结构,其有两个私有成员:一个DateTime类型的UTC,以及int类型的offset。如果是你在创建DateTimeOffset类型,那么你很可能只要UTC字段相等即可,而不去比较Offset字段。另外一个例子就是支持NaN的数字类型,比如float和double,如果你来创建这两个类型,你可能会希望NaN也是可以进行比较的。
而对于Class类型,很多时候,使用值比较更有意义。尤其是一些包含较少数据的类,比如System.Uri或System.String
2)提高结构类型的比较速度
结构类型的默认比较算法相对较慢。通过重写Equals方法可以提高5%的性能。而重载==运算和实现IEquatable<T>可以在不装箱操作的情况下实现相等性比较,这使得提高5%性能变得可能。
对于自定义相等比较,有一个特殊的情形,更改结构类型的hashing算法后,hashtable可以获得更好的性能。这是因为hashing算法和相等性比较都发生在栈上。
3)如何重写相等
总地来说,有下面三种方式:
I)重写GetHashCode
object对象的虚方法GetHashCode,也就仅仅对于Hashtable类型和Dictionary<TKey,TValue>类型有益。
这两个类型都是哈希表集合,集合中的每个元素都是一个键值用于存储元素和获取元素。哈希表使用了一个特定的策略以有效地基于元素的键值分配元素。这就要求每个键值都有一个Int32数(或哈希码)。哈希码不仅对于每个键值是唯一的,而且还必须有较好的性能。哈希表认为object类定义的GetHashCode方法已经足够了,因此这两个类型都省略了获取哈希码的方法。
无论值类型还是引用类型,都默认实现了GetHashCode方法,所以你不用重写这个方法,除非你需要重写Equals方法。(因此,如果你重写了GetHashCode方法,那么你肯定是需要重写Equals方法)。
是否需要重写GetHashCode方法,可以参考下面的规则:
为了提高哈希表的性能,GetHashCode需要重写以防止不同的值返回相同的哈希码。也这就说明了为什么需要对结构类型需要重写Equals和GetHashCode方法,因此这样重写比默认的哈希算法更有效率。结构类型的GetHashCode方法的默认实现是在运行时才发生,而且很可能基于结构的每个成员而实现。
// char typepublic override int GetHashCode() { return (int)m_value | ((int)m_value << 16);}// int32public override int GetHashCode() { return m_value;}
而类(class)类型,GetHashCode方法的默认实现基于内部对象标识,这个标识在CLR中对于每个对象实例都是唯一的。
public virtual int GetHashCode(){ return RuntimeHelpers.GetHashCode(this);}
II)重写Equals
object.Equal的规定(公理)如下:
新闻热点
疑难解答