56

When I implement objects that I want to compare using the IEquatable<T> interface:

  1. Why do I have to override Equals(object) method if I already implemented Equals(T)?
  2. Can I use == and != operators once I implement IEquatable<T>?
Improve this question

2 Answers 2

Reset to default
55

  1. From MS Docs article on IEquatable<T>:

    If you implement IEquatable<T>, you should also override the base class implementations of Equals(Object) and GetHashCode() so that their behavior is consistent with that of the Equals(T) method. If you do override Equals(Object), your overridden implementation is also called in calls to the static Equals(Object, Object) method on your class. In addition, you should overload the op_Equality and op_Inequality operators. This ensures that all tests for equality return consistent results.

  2. No, operators do not use the Equals method. They must be overloaded separately to do so.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

so when you are dealing with objects, is == assumed to only mean the exact same memory address (same instance)
Pretty much. More info here: msdn.microsoft.com/en-us/library/53k8ybth(VS.80).aspx
No, use ReferenceEquals() for that purpose. The equality operator (==) usually means the same, but can be overriden (e.g. for Strings and the like).
Slight terminology correction - you can't override operators, but you can overload them.
Yes, you can overload == and != in and use them in conjunction with the IEquatable interface. But this needs to be done manually, it doesn't come automatically with IEquatable. The "No" in part 2 of the answer is actually incorrect. Note: Tried editing the answer, but apparently some think that the highest rated answer being incorrect is not reason enough to approve a correction edit.
|
45

1) As Ray said, override Equals(object) to ensure consistency when the method is called from classes which don't know (statically) that you implement IEquatable<T>. For instance, the non-generic collections classes will use Equals(object) for comparisons. You should also override GetHashCode().

2) Implementing IEquatable<T> doesn't overload the == and != operators automatically, but there's nothing to stop you from doing so, just like System.String does. You should document this very clearly if you do, however - and be careful when you make comparisons between other types of reference (e.g. MyType and Object) which will still use the identity comparison. I suspect it's not a great idea to do this unless it's going to be a very heavily used type in your code, where everyone will become very familiar with it and where the syntactic sugar of overloading == will really make a positive impact on readability.

Improve this answer

4 Comments

Jon, is there any performance gain for an IEquatable<T> implementing type used for instance in a Collection<T>, calling the Contains method?
It will avoid casting, yes. For value types, it'll avoid boxing and unboxing as well. See the docs for Collection<T>.Contains - it uses EqualityComparer<T>.Default, which will use the IEquatable<T> implementation if possible.
Yes, it is not a good idea to overload operator == and != to provide value equality checks (vs the default reference equality check). The MSDN documentation suggests you only do it for immutable types. There are also issues involving interfaces and operator overloading.
See stackoverflow.com/questions/728434/… for more on both issues.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.