Menu
Why GetHashCode is part of the Object class? Only small part of the objects of the classes are used as keys in hash tables. Wouldn't it be better to have a separate interface which must be implemented when we want objects of the class to serve as keys in hash table.
There must be a reason that MS team decided to include this method in Object class and thus make it available "everywhere".
810
The purpose of the hashCode() method is to provide a numeric representation of an object's contents so as to provide an alternate mechanism to loosely identify it. By default the hashCode() returns an integer that represents the internal memory address of the object.
Why is it important to override GetHashCode ? It s important to implement both equals and gethashcode, due to collisions, in particular while using dictionaries. if two object returns same hashcode, they are inserted in the dictionary with chaining. While accessing the item equals method is used.
If you're implementing a reference type, you should consider overriding the Equals method if your type looks like a base type, such as Point, String, BigNumber, and so on. Override the GetHashCode method to allow a type to work correctly in a hash table.
GetHashCode method of the base class uses reflection to compute the hash code based on the values of the type's fields. In other words, value types whose fields have equal values have equal hash codes.
It was a design mistake copied from Java, IMO.
In my perfect world:
ToString would be renamed ToDebugString to set expectations appropriatelyEquals and GetHashCode would be goneReferenceEqualityComparer implementation of IEqualityComparer<T>: the equals part of this is easy at the moment, but there's no way of getting an "original" hash code if it's overriddenMonitor would have a constructor, and Enter/Exit etc would be instance methods.Equality (and thus hashing) cause problems in inheritance hierarchies in general - so long as you can always specify the kind of comparison you want to use (via IEqualityComparer<T>) and objects can implement IEquatable<T> themselves if they want to, I don't see why it should be on Object. EqualityComparer<T>.Default could use the reference implementation if T didn't implement IEquatable<T> and defer to the objects otherwise. Life would be pleasant.
Ah well. While I'm at it, array covariance was another platform mistake. If you want language mistakes in C#, I can start another minor rant if you like ;) (It's still by far my favourite language, but there are things I wish had been done differently.)
I've blogged about this elsewhere, btw.
144
Only small part of the objects of the classes are used as keys in hash tables
I would argue that this is not a true statement. Many classes are often used as keys in hash tables - and object references themselves are very often used. Having the default implementation of GetHashCode exist in System.Object means that ANY object can be used as a key, without restrictions.
This seems much nicer than forcing a custom interface on objects, just to be able to hash them. You never know when you may need to use an object as the key in a hashed collection.
This is especially true when using things like HashSet<T> - In this case, often, an object reference is used for tracking and uniqueness, not necessarily as a "key". Had hashing required a custom interface, many classes would become much less useful.
23
It allows any object to be used as a key by "identity". This is beneficial in some cases, and harmful in none. So, why not?
28
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
