How should I implement IEqualityComparer.Equals

Question

Concerning IEqualityComparer, is there ever a reason why the Equals(T x, T y) implementation should be anything other than what I have below?

public class MyEquality : IEqualityComparer<MyType>
{
    //My Equals(T x, T y) always looks like this
    public bool Equals(MyType x, MyType y)
    {
        return this.GetHashCode(x).Equals(this.GetHashCode(y));
    }

    public int GetHashCode(MyType obj)
    {
        //assume MyType has a non-nullable member called ID
        return obj.ID.GetHashCode();
    }
}

Joey · Accepted Answer · 2013-04-17T15:59:19.633

Yes. Hash codes can collide and in fact, they will with many types. They only exist to ensure equidistribution of values in hash tables, they are not useful for determining equality of values. Eric Lippert has also a take on this (and another one):

It is a really bad idea to use 32 bit hash codes as “unique” identifiers. Hash values aren't random per se, but if they're well-distributed then they might as well be for our purposes. You might think “well, sure, obviously they are not truly unique since there are more than four billion possible values, but only four billion hash codes available. But there are so many possible hash values, odds are really good that I’m going to get unique values for my hashes”. But are the chances really that good? 9300 objects is not that many and 1% is a pretty high probability of collision.

That being said, if your ID is the only thing you care for when determining equality, then comparing that ID should suffice. But not its hash code because a hash code only says

a.GetHashCode() ≠ b.GetHashCode() → a ≠ b

Note that nothing is said about the case where the hash code is the same.

In other words, `if (a.GetHashCode() != b.GetHashCode()) return false` is half of the method. The other half is comparing the actual values of objects `a` and `b`, since they have the same hashcode. — David R Tribble, Apr 17 '13 at 17:28
That is, if calculating the hash codes is actually less work than just comparing the values. Since they usually access the same fields I guess there is little benefit to access all fields twice just to jump out early if the hash code doesn't match (as opposed to, say, jump out early because the first comparison already returned `false`). — Joey, Apr 17 '13 at 18:19

Sergey Kalinichenko · Answer 2 · 2013-04-17T15:52:37.477

Yes, there is: if ID's hash code does not fit in an int, now or some time in the future, you would be in for a nasty surprise, when unequal objects with identical hash codes start evaluating as equals. If at a later date someone decides that ID should be long or Guid, MyEquality would continue to happily compile, but its behavior would be hopelessly incorrect.

On an unrelated note, if MyType is a class, you may want to do something about preventing crashes when x or y is null: although the contract of IEqualityComparer<T> does not explicitly calls for it (unlike object.Equals that does) it is a good idea to deal with nulls in IEqualityComparer<T>.Equals in situations when you search through containers that may include null objects.

score 0 · Answer 3 · answered Apr 17 '13 at 15:44

0

Sure. You could have an object where you're only concerned about one or more properties being the same to consider them equal for your purposes.

answered Apr 17 '13 at 15:44

Rohrbs

1,855
13
11

score 0 · Answer 4 · answered Apr 17 '13 at 15:45

If you would compare List list1, and List list2, if they have some "common" element, for instance list1={"apparent", "obvious"}, and list2={"aPPARENT", "oBVIOUS"}

if your definition of equity is as follows:

the first character must be equal, case sensitive
the remainder character must not be equal (case sensitive)

you must define your own logic in your IEqualityComparer.

Besides, in LINQ, all the Where, Any, Except, Intersect etc. clauses may require additional IEqualityComparer object for you to hook you custom logic.

How should I implement IEqualityComparer.Equals

4 Answers4