如标题所示:我需要覆盖==
运算符吗?.Equals()
方法怎么样?我有什么想念的吗?
Answers:
来自msdn的示例
public struct Complex
{
double re, im;
public override bool Equals(Object obj)
{
return obj is Complex c && this == c;
}
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);
}
}
Complex other = obj as Complex
,然后检查other == null
,而不是使用is
,然后铸...
Complex? other = obj as Complex?
,但可为空的类型通常不适合效率。
MyComplex
按您的建议派生a 。
您还应该实现IEquatable <T>。这是《框架设计指南》的节选:
不要在值类型上实现IEquatable。值类型上的Object.Equals方法会引起装箱,并且其默认实现不是很有效,因为它使用了染感。IEquatable.Equals可以提供更好的性能,并且可以实现,从而不会引起装箱。
public struct Int32 : IEquatable<Int32> {
public bool Equals(Int32 other){ ... }
}
在实现IEquatable.Equals时,请遵循与重写Object.Equals相同的准则。有关覆盖Object.Equals的详细准则,请参见8.7.1节。
不幸的是,我没有足够的声誉来评论其他条目。因此,我在此处发布了对顶级解决方案的可能增强。
纠正我,如果我错了,但是上面提到的实现
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);
}
}
有重大缺陷。我指的是
public override int GetHashCode()
{
return re.GetHashCode() ^ im.GetHashCode();
}
XORing是对称的,因此Complex(2,1)和Complex(1,2)会给出相同的hashCode。
我们可能应该做一些类似的事情:
public override int GetHashCode()
{
return re.GetHashCode() * 17 ^ im.GetHashCode();
}
大多数时候,您可以避免在结构中实现Equals和GetHashcode-因为编译器会自动对Value类型使用引用成员的按位内容+反射来实现。
看一下那篇文章: 哪种数据存储结构/类最好?
因此,为了易于使用,您仍然可以实现==和!=。
但是大多数时候,您可以避免实现Equals和GetHashcode。
在这种情况下,您必须实现Equals和GetHashCode,这是您不希望考虑的字段。
例如,随着时间的流逝而变化的字段,例如“人的年龄”或“汽车的瞬时速度”(如果要在同一位置的字典中找到对象,则对象的身份不应更改)
关于最好的代码
仅出于完整性,我还建议重载Equals
方法:
public bool Equals(Complex other)
{
return other.re == re && other.im == im;
}
这是真正的改进,因为没有输入的自变量发生装箱 Equals(Object obj)
方法
使用值类型的一些最佳做法:
来自这篇文章:http : //theburningmonk.com/2015/07/beware-of-implicit-boxing-of-value-types/