问题
As the title says: do I need to override the ==
operator? how about the .Equals()
method? Anything I'm missing?
回答1:
An example from msdn
public struct Complex
{
double re, im;
public override bool Equals(Object obj)
{
return obj is Complex && this == (Complex)obj;
}
public override int GetHashCode()
{
return re.GetHashCode() ^ im.GetHashCode();
}
public static bool operator ==(Complex x, Complex y)
{
return x.re == y.re && x.im == y.im;
}
public static bool operator !=(Complex x, Complex y)
{
return !(x == y);
}
}
回答2:
You should also implement IEquatable<T>. Here is an excerpt from Framework Design Guidelines:
DO implement IEquatable on value types. The Object.Equals method on value types causes boxing, and its default implementation is not very effcient because it uses refection. IEquatable.Equals can offer much better performance and can be implemented so that it does not cause boxing.
public struct Int32 : IEquatable<Int32> {
public bool Equals(Int32 other){ ... }
}
DO follow the same guidelines as for overriding Object.Equals when implementing IEquatable.Equals. See section 8.7.1 for detailed guidelines on overriding Object.Equals
回答3:
Unfortunetely I don't have enough reputation to comment other entries. So I'm posting possible enhancement to the top solution here.
Correct me, if i'm wrong, but implementation mentioned above
public struct Complex
{
double re, im;
public override bool Equals(Object obj)
{
return obj is Complex && this == (Complex)obj;
}
public override int GetHashCode()
{
return re.GetHashCode() ^ im.GetHashCode();
}
public static bool operator ==(Complex x, Complex y)
{
return x.re == y.re && x.im == y.im;
}
public static bool operator !=(Complex x, Complex y)
{
return !(x == y);
}
}
Has major flaw. I'm refering to
public override int GetHashCode()
{
return re.GetHashCode() ^ im.GetHashCode();
}
XORing is symmetrical, so Complex(2,1) and Complex(1,2) would give same hashCode.
We should probably make something more like:
public override int GetHashCode()
{
return re.GetHashCode() * 17 ^ im.GetHashCode();
}
回答4:
Most of the time you can avoid implementing Equals and GetHashcode in structs - because there is an automatic implementation by the compiler for Value types using bitwise content + reflection for reference members.
Have a look at that post : Which is best for data store Struct/Classes?
So for ease of use you could still implement == and !=.
But most of the time you can avoid implementing Equals and GetHashcode.
A case where you'd have to implement Equals and GetHashCode is for a field that you don't wan't to take into account.
For instance a field that varies as time goes by like Age of a Person or instantSpeed of a car( the identity of the object shouldn't change if you want to find it back in the dictionary at the same place)
Regards, best code
回答5:
The basic difference among the two is that the ==
operator is static, i.e. the appropriate method to invoke is determined at compile time, while the Equals
method is invoked dinamically on an instance.
Defining both is probably the best thing to do, even if this matters less in the case of structs, since structs cannot be extended (a struct can't inherit from another).
回答6:
Just for completness I would also advice to overload Equals
method:
public bool Equals(Complex other)
{
return other.re == re && other.im == im;
}
this is a real spead improvement as there is no boxing occuring of the input argument of Equals(Object obj)
method
Some best practices for using value types:
- make them immutable
- override Equals (the one that takes an object as argument);
- overload Equals to take another instance of the same value type (e.g. * Equals(Complex other));
- overload operators == and !=;
- override GetHashCode
This comes from this post: http://theburningmonk.com/2015/07/beware-of-implicit-boxing-of-value-types/
来源:https://stackoverflow.com/questions/1502451/what-needs-to-be-overridden-in-a-struct-to-ensure-equality-operates-properly