Tuesday, 29 August 2006

Every now and then somebody just has to do it. They need to override the GetHashCode method either because overriding Equals method or for some other reason. Doing so, you should follow the guidelines provided to us by one and only Microsoft:


The main problem with guidelines regarding the GetHashCode method is that the change from time to time which causes some confusion.

The last change I have noticed is the fact that now GetHashCode can return different values for the same object if the state of the object that the GetHashCode relies on, has been modified. Previously GetHashCode allways had to return the same value for a given object (which caused it alomost impossible to override both the GetHashCode method and the Equals method and at the same time have a mutable object). The change to the rule makes it easier, but has some other implications...

The most important implication of having an object return a different hash code during its lifetime is the fact that no it is possible to put someting in the hashtable never to be seen again (at least not in a way we would expect it to). When this happens is when we put some value in the hashtable using some object as a key. Then we change the object so that it returns a different hash code and we have a situation where the value in the hashtable is inaccessible using the same key we have used to put it there.

As a quick example try the following code:

public class Class1
public override int GetHashCode()
return new Random().Next();

public static void Test()
Hashtable t = new Hashtable();
Class1 c1 = new Class1();
t.Add(c1, 1);
Class1 c2 = new Class1();
t.Add(c2, 2);
object o1 = t[c1];
object o2 = t[c2];

What would you expect o1 and o2 to be? Given no knowledge of the hashtable object I would expect to get what I have put earlier i.e.: 1 and 2, but I get nulls. That is because the Hashtable uses the GetHashCode method as a key to find values. Keep this in mind when overriding the nasty method.

kick it on DotNetKicks.com