More on Hashcodes
One of the devs on the BCL team just
added a bit to my recent
post on hashcodes…
Enjoy!
Brad's comment above applies to Object's GetHashCode
implementation, which most interesting classes override, providing their own
hash function. We believe GetHashCode should be used as a hash function that
returns a seemingly-random value that could be negative or duplicated for
multiple values. In V1, Object's GetHashCode unfortunately gave some stronger
guarantees than this that a few people wanted to depend on, but that wasn't in
the contract of the method. Their code is already broken on version 2 (we think
the only people that depended on this were internal the company, and they would
have long since found their bug & corrected it).
Note that we also don't want user code taking a dependency on
our existing hash function implementations for any type - ideally we could
change them every time we build the product. To elaborate on that, let's look at
String.
String uses a different hash
function that looks at each character, XOR'ing in the new character with a
(presumably prime) number. We'll change String's hash function in a future
version so it both executes faster and produces a better distribution. This will
improve lookups in hash tables when using strings as keys. But because we'll
change the hash function, it is also important to not depend on one particular
version's implementation of GetHashCode. IE, never write the values you get back
from GetHashCode to disk and read them back later, or sort values based on their
hash function then persist that data to a file or send it over a
network.
Brian Grunkemeyer
MS CLR Base Class Library team
