what happens if I skip implementing GetHashCode

[Tony]

Hello!

Here I have a Card class with several methods.

Now to my question I don't really fully understand what purpose this
GetHashCode is used for.
That's why I bring it up again.
In this simple example below with the Card class what would happen if I skip
this GetHashCode in this Card class?
Is it possible to write some simple test program to prove that this
GetHashCode will prevent
error or problem to occur?

class Card
{
//rank and suit are defined here
public static bool operator==(Card card1, Card card2)
{
return card1.suit == card2.suit) && (card1.rank==ca rd2.rank);
}

public override bool Equals(object card)
{
return this == (Card) card;
}

public override int HetHashCode()
{
return 13*(int)rank + (int)suit;
}
....
....
}

//Tony

[Peter Duniho]

Re: what happens if I skip implementing GetHashCode

On Fri, 13 Jun 2008 00:01:31 -0700, Tony <johansson.ande rsson@telia.com >
wrote:

[...]
Now to my question I don't really fully understand what purpose this
GetHashCode is used for.
That's why I bring it up again.
In this simple example below with the Card class what would happen if I
skip
this GetHashCode in this Card class?

Then hash table implementations will treat two instances that might have
compared as equal as if they are not equal. Likewise anything else that
might use the hash code.

If you never use instances of this class as keys in a hash table or with
anything else that cares about the hash code, it won't matter.

If you do decide to go ahead and implement GetHashCode() (and IMHO, why
not?), you should probably spell the name of the method correctly. :)

If you need more information about how hash codes are used, I'd suggest a
good computer science text on the subject. A newsgroup isn't the best way
to educate oneself on such things, it being a relatively advanced topic
deserving of much more than one or a few newsgroup posts.

Pete

[Tony]

Re: what happens if I skip implementing GetHashCode

Hello!!

Now we assume that I store instances of Card as key in some sort of hash
table or similar things.

According to you will the hash table implementations treat two instances
that might have
compared as equal as if they are not equal.what will happen then?

//Tony



"Peter Duniho" <NpOeStPeAdM@nn owslpianmk.coms krev i meddelandet
news:op.ucoeh5g 38jd0ej@petes-computer.local. ..

On Fri, 13 Jun 2008 00:01:31 -0700, Tony <johansson.ande rsson@telia.com >
wrote:
>

[...]
Now to my question I don't really fully understand what purpose this
GetHashCode is used for.
That's why I bring it up again.
In this simple example below with the Card class what would happen if I
skip
this GetHashCode in this Card class?

>
Then hash table implementations will treat two instances that might have
compared as equal as if they are not equal. Likewise anything else that
might use the hash code.
>
If you never use instances of this class as keys in a hash table or with
anything else that cares about the hash code, it won't matter.
>
If you do decide to go ahead and implement GetHashCode() (and IMHO, why
not?), you should probably spell the name of the method correctly. :)
>
If you need more information about how hash codes are used, I'd suggest a
good computer science text on the subject. A newsgroup isn't the best way
to educate oneself on such things, it being a relatively advanced topic
deserving of much more than one or a few newsgroup posts.
>
Pete

[Jon Skeet [C# MVP]]

Re: what happens if I skip implementing GetHashCode

On Jun 13, 8:39 am, "Tony" <johansson.ande rs...@telia.com wrote:

Now we assume that I store instances of Card as key in some sort of hash
table or similar things.
>
According to you will the hash table implementations treat two instances
that might have
compared as equal as if they are not equal.what will happen then?

Suppose you store some value with the key "10 of spades". Later you
create a new but equal "10 of spades" - you'd like to be able to look
up the value in the hash table using the new "10 of spades", but if it
gives a different hash code to the original key, the hashtable won't
find the entry.

Jon

[Peter Duniho]

Re: what happens if I skip implementing GetHashCode

On Fri, 13 Jun 2008 00:39:06 -0700, Tony <johansson.ande rsson@telia.com >
wrote:

Hello!!
>
Now we assume that I store instances of Card as key in some sort of hash
table or similar things.
>
According to you will the hash table implementations treat two instances
that might have
compared as equal as if they are not equal.what will happen then?

It will be as if the two aren't equal, just as I said. In that scenario,
you might as well not have overridden the Equals() method, because the
test for equality in the hash table will never get that far. The hash
table won't even bother calling Equals() unless GetHashCode() returns the
same value, and if you don't override GetHashCode() it won't except for
the same instance.

And of course, the consequence of that will be the same as for any other
reason that the key might test as not equal. You won't find an entry in
the hash table except by using the exact instance used to add it to the
hash table, and adding a value to the hash table using a key other than
the exact instance used to add some other value previously will succeed,
even if the key's Equals() methods would have returned true for some other
key already in the hash table.

Pete

[Peter Morris]

Re: what happens if I skip implementing GetHashCode

At least override it and throw a NotImplementedE xception.

[Tony]

Re: what happens if I skip implementing GetHashCode

Hello!

Well it's not possible to add two key that are the same to a hashtable.
Have I missed something here?
Jon mentioned that the key was "10 of spades" when trying to add this a
second time it will complain?

//Tony

"Peter Duniho" <NpOeStPeAdM@nn owslpianmk.coms krev i meddelandet
news:op.ucogpim e8jd0ej@petes-computer.local. ..

On Fri, 13 Jun 2008 00:39:06 -0700, Tony <johansson.ande rsson@telia.com >
wrote:
>

Hello!!

Now we assume that I store instances of Card as key in some sort of hash
table or similar things.

According to you will the hash table implementations treat two instances
that might have
compared as equal as if they are not equal.what will happen then?

>
It will be as if the two aren't equal, just as I said. In that scenario,
you might as well not have overridden the Equals() method, because the
test for equality in the hash table will never get that far. The hash
table won't even bother calling Equals() unless GetHashCode() returns the
same value, and if you don't override GetHashCode() it won't except for
the same instance.
>
And of course, the consequence of that will be the same as for any other
reason that the key might test as not equal. You won't find an entry in
the hash table except by using the exact instance used to add it to the
hash table, and adding a value to the hash table using a key other than
the exact instance used to add some other value previously will succeed,
even if the key's Equals() methods would have returned true for some other
key already in the hash table.
>
Pete

[Tony]

Re: what happens if I skip implementing GetHashCode

Hello!

If I for example use a string as a key and a person as a value and add this
item to a hashtable this will never be any
problem because it matters only when key is a instance.
Is this right?

//Tony

"Peter Duniho" <NpOeStPeAdM@nn owslpianmk.coms krev i meddelandet
news:op.ucogpim e8jd0ej@petes-computer.local. ..

On Fri, 13 Jun 2008 00:39:06 -0700, Tony <johansson.ande rsson@telia.com >
wrote:
>

Hello!!

Now we assume that I store instances of Card as key in some sort of hash
table or similar things.

According to you will the hash table implementations treat two instances
that might have
compared as equal as if they are not equal.what will happen then?

>
It will be as if the two aren't equal, just as I said. In that scenario,
you might as well not have overridden the Equals() method, because the
test for equality in the hash table will never get that far. The hash
table won't even bother calling Equals() unless GetHashCode() returns the
same value, and if you don't override GetHashCode() it won't except for
the same instance.
>
And of course, the consequence of that will be the same as for any other
reason that the key might test as not equal. You won't find an entry in
the hash table except by using the exact instance used to add it to the
hash table, and adding a value to the hash table using a key other than
the exact instance used to add some other value previously will succeed,
even if the key's Equals() methods would have returned true for some other
key already in the hash table.
>
Pete

[Jon Skeet [C# MVP]]

Re: what happens if I skip implementing GetHashCode

On Jun 13, 9:51 am, "Tony" <johansson.ande rs...@telia.com wrote:

Well it's not possible to add two key that are the same to a hashtable.
Have I missed something here?
Jon mentioned that the key was "10 of spades" when trying to add this a
second time it will complain?

I wasn't suggesting adding it a second time - just using it to fetch.

However, if you *did* try to add it a second time, you would succeed
if the hash code was different, because again the hashtable wouldn't
be able to detect that the key was already present.

Jon

[Jon Skeet [C# MVP]]

Re: what happens if I skip implementing GetHashCode

On Jun 13, 10:03 am, "Tony" <johansson.ande rs...@telia.com wrote:

If I for example use a string as a key and a person as a value and add this
item to a hashtable this will never be any
problem because it matters only when key is a instance.
Is this right?

Exactly. Values aren't checked for equality and their hashcodes aren't
used.

Jon

[Peter Duniho]

Re: what happens if I skip implementing GetHashCode

On Fri, 13 Jun 2008 01:51:10 -0700, Tony <johansson.ande rsson@telia.com >
wrote:

Well it's not possible to add two key that are the same to a hashtable.
Have I missed something here?

Yes. You keep thinking that you are talking about "two key that are the
same". But that's the point: if the hash code is different, the two keys
aren't the same. Even if the Equals() method says they are.

Pete