Appropriate GetHashCode() override?

[=?Utf-8?B?RXRoYW4gU3RyYXVzcw==?=]

Hi,
I have a moderately complex class (about 10 different string and int
type fields along with two different List<stringfields). I want to override
Equals(), so I need to override GetHashCode(). The standard override for
GetHashCode() for something would be to join GetHashCode for each field with
^ (XOR). Right? But, in this case, one of the fields is a "Unique" Identifier
and SHOULD uniquely identify the instance of the class. If that is the case,
is it acceptable to just use the HashCode for that uniqueID field as the
HashCode for the instance? What if there are two different instances with
the same "Unique" identifier, but different contents (which is what I am
looking for with my Equals() override)? If they evaluate to the same HashCode
will that cause major issues?

Thanks!
Ethan

[Lee]

Ethan,

There is a great blog entry about this very thing here:
http://blog.roblevine.co.uk/?p=13

But to summarize, if two things are Equal(), there HashCode MUST be
the same and if they are not equal, they CANNOT be the same.

Then again, all this is moot if you never are going to use the class
is a container that uses the HashCode. (Not usually a safe bet due to
possible future enhancements to the codebase)

L. Lee Saunders
http://oldschooldotnet.blogspot.com

[Peter Duniho]

On Fri, 14 Nov 2008 09:25:00 -0800, Lee <sa******@hotmail.comwrote:

Ethan,

There is a great blog entry about this very thing here:
http://blog.roblevine.co.uk/?p=13

But to summarize, if two things are Equal(), there HashCode MUST be
the same and if they are not equal, they CANNOT be the same.

That's not a reasonable summary of the article, or of the requirements of
a hash code. It's true that if two things are equal, the hash codes
returned by those things must also be equal. But it is definitely _not_
true that when the two things are not equal that the hash codes "CANNOT be
the same". In fact, if that were possible then we could skip using the
Equals() method altogether and only use GetHashCode().

Then again, all this is moot if you never are going to use the class
is a container that uses the HashCode. (Not usually a safe bet due to
possible future enhancements to the codebase)

If you override Equals(), you should definitely override GetHashCode() to
match.

Pete

[Peter Duniho]

On Fri, 14 Nov 2008 08:44:13 -0800, Ethan Strauss
<Et**********@discussions.microsoft.comwrote:

Hi,
I have a moderately complex class (about 10 different string and int
type fields along with two different List<stringfields). I want to
override
Equals(), so I need to override GetHashCode(). The standard override for
GetHashCode() for something would be to join GetHashCode for each field
with
^ (XOR). Right? But, in this case, one of the fields is a "Unique"
Identifier
and SHOULD uniquely identify the instance of the class.

"Uniquely identify" how? If that field isn't the sole field used for the
Equals() method, then why not? Why bother to check other fields when this
one field can tell you that two instances are equal or not?

Conversely, if more than just this one field is involved in equality, then
how can you say that a single field does in fact "uniquely identify the
instance of the class"? I mean, literally speaking the _reference_ to the
instance is a unique identifier, but if that were really sufficient for
your needs, you wouldn't have to override Equals() at all. So you must
not mean the _instance_ is uniquely identified but rather the data
represented by it.

If that is the case,
is it acceptable to just use the HashCode for that uniqueID field as the
HashCode for the instance? What if there are two different instances
with
the same "Unique" identifier, but different contents (which is what I am
looking for with my Equals() override)? If they evaluate to the same
HashCode
will that cause major issues?

You need to step back and figure out why your definitions of "unique" and
"equals" don't match. It is true that you must _not_ use that single
field for your hash code if other fields are included in the Equals()
test, but the very fact that you're asking about this means that you
haven't fully resolved what it means for two instances of your class to be
equal. Until you figure that out, you can't possible successfully
implement Equals() and GetHashCode().

By the way, do _not_ composite hash codes using XOR. You will
unnecessarily introduce collisions at a remarkably high rate. The
accepted practice is to use an accumulator, multiplying by a prime number
between each addition of the next field's hash code. Search this
newsgroup for past discussions of hash codes for more details.

Pete

[=?Utf-8?B?RXRoYW4gU3RyYXVzcw==?=]

Hi Pete,
Thanks for you comments. In this case, I am populating this class by
pulling data from a database using a WebService. The "Unique" identifier
uniquely identifies a record in the main database table, but I am getting a
bunch of related data as well and I suspicious that I not always getting
exactly the same related data. One of my main goals right now is to see if it
is, in fact, always the same. I guess this means that I don't consider it
unique and should write GetHashCode as though it is not. I will probably go
ahead and rewrite the GetHashCode as described in
http://blog.roblevine.co.uk/?p=19.

>By the way, do _not_ composite hash codes using XOR. You will
unnecessarily introduce collisions at a remarkably high rate. The
accepted practice is to use an accumulator, multiplying by a prime number
between each addition of the next field's hash code. Search this
newsgroup for past discussions of hash codes for more details.

Given this (and I now agree with it), Microsoft should really change the
documentation for GetHashCode
(http://msdn.microsoft.com/en-us/libr...thashcode.aspx ).
This more or less tells you to just XOR everything together.

Ethan

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Ethan Strauss wrote:

I have a moderately complex class (about 10 different string and int
type fields along with two different List<stringfields). I want to override
Equals(), so I need to override GetHashCode(). The standard override for
GetHashCode() for something would be to join GetHashCode for each field with
^ (XOR). Right? But, in this case, one of the fields is a "Unique" Identifier
and SHOULD uniquely identify the instance of the class. If that is the case,
is it acceptable to just use the HashCode for that uniqueID field as the
HashCode for the instance?

If the Equals overload just compares those ids, then having HashCode
return the has code of the id is a good solution.

What if there are two different instances with
the same "Unique" identifier, but different contents (which is what I am
looking for with my Equals() override)? If they evaluate to the same HashCode
will that cause major issues?

Having Equals compare other fields than the id and have HashCode return
only the hash code of the id is valid, but in my opinion not good style.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Lee wrote:

There is a great blog entry about this very thing here:
http://blog.roblevine.co.uk/?p=13

But to summarize, if two things are Equal(), there HashCode MUST be
the same and if they are not equal, they CANNOT be the same.

I hope that your summary are wrong, since in general objects
can return same HashCode even if Equals return false.

Arne