3

I just want to confirm my understanding of a few fundamentals. Hope you don't mind!

I understand the static equals method 

Object.Equals(objA, objB)

first checks for reference equality. If not equal by reference, then calls the object instance equals method

objA.Equals(objB)

Currently in my override for equals, i first check for reference equality, and if not equal referentially then check with all members to see if the semantics are the same. Is this a good approach? If so, then the static version seems superfluous?

Also what exactly does the default GetHashCode for an object do?

If I add my object to a dictionary which is a HashTable underneath and don't override equals and GetHashCode, then I guess I should do to make it sort optimally hence better retrieval time?

Zivka
  • 929
  • 1
  • 7
  • 7
  • I thionk MSDN is the best source for your questions: http://msdn.microsoft.com/en-us/library/336aedhh(v=vs.100).aspx and http://msdn.microsoft.com/en-us/library/system.object.gethashcode(v=vs.100).aspx – Sedat Kapanoglu Jan 26 '12 at 14:42

2 Answers2

2

Currently in my override for equals, i first check for reference equality, and if not equal referentially then check with all members to see if the semantics are the same. Is this a good approach? If so, then the static version seems superfluous?

Yes, it's a great idea to do the fast reference-equality check. There's no guarantee that your method will be called through the static Object.Equals method - it could well be called directly. For example, EqualityComparer<T>.Default (the typical middleman for equality checking) will directly call this method in many situations (when the type does not implement IEquatable<T>) without first doing a reference-equality check.

Also what exactly does the default GetHashCode for an object do?

It forwards toRuntimeHelpers.GetHashCode: a magic, internally-implemented CLR method that is a compliant GetHashCode implementation for reference-equality. For more information, see Default implementation for Object.GetHashCode(). You should definitely override it whenever you override Equals.

EDIT:

If I add my object to a dictionary which is a HashTable underneath and don't override equals and GetHashCode, then I guess I should do to make it sort optimally hence better retrieval time?

If you don't override either, you'll get reference-equality with (probably) a well-balanced table. If you override one but not the other or implement them in any other non-compliant way, you'll get a broken hashtable.

By the way, hashing is quite different from sorting.

For more information, see Why is it important to override GetHashCode when Equals method is overriden in C#?

Community
  • 1
  • 1
Ani
  • 111,048
  • 26
  • 262
  • 307
2

Your first question was already answered, but I think the second was not fully answered.

Implementing your GetHashCode is important if you want to use your object as a key in a hash table or a dictionary. It minimizes collisions and therefore it speeds the lookup. A lookup collision happens when two or more keys have the same hashcode and for those equals method is invoked. If the hashcode is unique, an equals will only be called once, otherwise it will be called for every key with the same hashcode until the equals returns true.

Rado
  • 8,634
  • 7
  • 31
  • 44
  • So am I right in saying that a good hash function will return unique values for all unequal objects? Also if object A is very similar but not the same as object B but object C is vastly different, then object A and B will be located close together in the hash table (have similar hash values) but object C further apart? – Zivka Jan 26 '12 at 14:45
  • 1
    @Zvika - generally, you *don't* want similar items to have similar hash codes. Read Eric Lippert's [Guidelines](http://blogs.msdn.com/b/ericlippert/archive/2011/02/28/guidelines-and-rules-for-gethashcode.aspx) – Damien_The_Unbeliever Jan 26 '12 at 15:52
  • For your first question, yes, a good hashcode function will ideally return a unique value for all unequal objects. Now for your second question, it doesn't really matter if similar objects return values that are close. After all, Equals will be called in the end regardless whether your HashCode function returns a unique value or not. you just want to minimize how many times equals is called. What you could do to optimize the placing of items in the hashtable is to have the distribution of HashCode values as sparse as possible regardless of whether two objects are "similar" – Rado Jan 26 '12 at 15:56