http://blogs.msdn.com/brada/archive/2003/09/30/50396.aspxOne of the architects on the CLR team just reminded me of a detail about GetHashCode on object… Specifically you should NOT use it as a unique ID for an object. It is possible for two different objects to return the same value. By the contract of GetHashCodeen-USCommunityServer 2.1 SP1 (Build: 61025.2)http://blogs.msdn.com/brada/archive/2003/09/30/50396.aspx#50397Wed, 01 Oct 2003 00:53:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:50397jeff clausiusbrad: point noted. one quick question. do you happen to know which hashing algorithm is used on the System.String class? i don't believe the id coming from get hash code is from the sync block, but rather a hash of the strings contents. am i wrong?http://blogs.msdn.com/brada/archive/2003/09/30/50396.aspx#50398Wed, 01 Oct 2003 06:05:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:50398Brian GrunkemeyerBrad'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 teamhttp://blogs.msdn.com/brada/archive/2003/09/30/50396.aspx#50399Sat, 15 Nov 2003 02:12:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:50399damien mortonA usefull addition to the BCL would be a standardised way of combining hashcodes that is a little more sophisticated than the hashcode-xor strewn through the MSDN documentation. A simple 32-bit linear conguential hash might suffice.http://blogs.msdn.com/brada/archive/2003/09/30/50396.aspx#226032Mon, 06 Sep 2004 15:05:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:226032Sriram KrishnanChasing the hash codehttp://blogs.msdn.com/brada/archive/2003/09/30/50396.aspx#237172Sun, 03 Oct 2004 14:28:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:237172Hackward and Foreword