演算子 == を定義して、Equals() または GetHashCode() を定義しないことの何が問題なのでしょうか? 質問する

演算子 == を定義して、Equals() または GetHashCode() を定義しないことの何が問題なのでしょうか? 質問する

以下のコード

public struct Person
{
    public int ID;
    public static bool operator ==(Person a, Person b) { return  a.Equals(b); }
    public static bool operator !=(Person a, Person b) { return !a.Equals(b); }
}

コンパイラがこれらの警告を出すのはなぜですか?
以下のメソッドを定義しないと何が問題になるのでしょうか?

warning CS0660: 'Person' defines operator == or operator != but
    does not override Object.Equals(object o)

warning CS0661: 'Person' defines operator == or operator != but
    does not override Object.GetHashCode()

ベストアンサー1

編集==: この回答は修正されました。ユーザー定義の値型は を生成しないこと、および のパフォーマンスの問題に言及していることなどが修正されました。ValueType.Equals


一般的に、すべてではなく 1 つをオーバーライドすると混乱が生じます。ユーザーは、どちらもオーバーライドされないか、または同じセマンティクスで両方がオーバーライドされることを予期しています。

マイクロソフトの推奨事項この州については(とりわけ):

  • Equals メソッドを実装するときは必ず GetHashCode メソッドを実装します。これにより、Equals と GetHashCode が同期されます。

  • 等価演算子 (==) を実装するときは常に Equals メソッドをオーバーライドし、同じことを実行するようにします。

あなたの場合、 を延期しEquals(コンパイラは を自動的に実装しない==)、これら 2 つ ( ==/ !=) のみをオーバーライドする正当な理由があります。ただし、 はリフレクションを使用するため、パフォーマンスの問題がまだありますValueType.Equals

「特定の型の Equals メソッドをオーバーライドして、メソッドのパフォーマンスを向上させ、その型の等価性の概念をより厳密に表現します。」

したがって、最後にすべてをオーバーライド ( ==// !=)することをお勧めします。もちろん、この単純な構造体ではパフォーマンスは問題にならないかもしれません。Equals

おすすめ記事