SYSK 98: Digging Deeper Into GetHashCode

So, you think you understand when, how and why to override GetHashCode?  Then you should be able to answer the following question:  will get message box in the code below say “true” or “false”:

public class MyClass


    private string _param;


    public string Param


        get { return _param; }

        set { _param = value; }




. . .


MyClass c1 = new MyClass();

c1.Param = "Some string";



MyClass c2 = new MyClass();

c2.Param = "Some string";


MessageBox.Show((c1.GetHashCode() == c2.GetHashCode()).ToString());


The answer is “False”.


Why?  Because it’s not about the data the object contains – it’s about the object instance.  More over, the c1.Equals(c2) will also return False.


So, if I change the code to look like this:

MyClass c1 = new MyClass();

c1.Param = "Some string";


MyClass c2 = c1;

c2.Param = "Some other string";


what do you think the result will be?  Yes, it’ll be “True”.  More over, both c1.Param and c2.Param will now be “Some other string”.


That’s why if you want you custom class to return True when the data is the same, even though the object instance is different, you need to override and implement your own logic in Equals and GetHashCode methods, which is exactly what the string class does.


For more information on Object.GetHashCode, visit



Comments (4)

  1. Eric says:

    Hi Irena,

    I’m not sure if I agrre with tour answer. IMHO the correct answer should be "true".

    The documented states that the main use for GetHashCode is to be used as key values in hash tables. For this kinf of use, distinct instances that represent the same object shouldn’t return the same hash? After all that is the advantage of using hash tables instead of ordinary lists. any number os "copies" os some object would be stored only once.

    Another way to look at your problem that leads to the same conclusion: your class behaves exactly like a ValueType, and so the return value of GetHashCode should be the same.

    Don’t you agree?

  2. Peter Ritchie says:

    In my first read of this, I got the impression that you were suggesting GetHashCode should *not* be implemented to use the data (or value) of the object.

    You should make it clear that MyClass inherits Object.GetHashCode() that is likely never going do anything with the data members of MyClass in the generation of the hash code.  Which is the reason the results are what they are.

    Simply inheriting Object.GetHashCode() (i.e. not overridding it) violates one of GetHashCode’s contracts: "If two objects of the same type represent the same value, the hash function must return the same constant value for either object."

    It’s probably also worth noting that it’s impossible to fufill both the above contract and another of GetHashCode’s contracts: "The hash function must return exactly the same value regardless of any changes that are made to the object."  Ian Griffiths has a good rant on this contradiction here:

  3. irenake says:

    One could think so…  But give it a shot — try it for yourself and you’ll see that the post is accurate.

  4. The AppDev: Something You Should Know is a great blog to read/subscribe to, it has loads of useful…

Skip to main content