The pigeonhole principle says no. A GUID has 16 bytes of information - 128 bits. An int
has 32 bits of information. (EDIT: To clarify due to comments, the .NET GUID will allow these 128 bits to be set arbitrarily as far as I'm aware; randomly generated GUIDs follow a stricter pattern so there aren't 2128 different values which would be randomly generated. Still more than 232 though.)
There are 2128 possible GUIDs, and 232 possible hash codes - so you can't possibly have a different hash code for each GUID.
There's more than that though - GetHashCode()
is never meant to represent uniqueness. If it can, then that's great - but it doesn't have to, even when there are enough int
values available to do so.
It would be entirely valid for int.GetHashCode()
to return (say) the value divided by two... so -1, 0 and 1 would all get a hash code of 0; 3 and 4 would get a hash code of 2 etc. It wouldn't be good (and it would be slower than just returning the value) - but it would be a valid implementation. It would satisfy all the constraints of GetHashCode
- namely that if you call it on two equal values, it will return the same hash code.
In fact, returning a constant for all values is a valid implementation - although a pretty useless one, in that it renders the normally-fast lookup of a hash table into an O(N) operation.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…