5

Let's assume I have two objects called K and M

if(K.Equals(M))
{

}

If that's true, K and M always has the same HashCode ?

Or It depends on the programming language ?

nawfal
  • 70,104
  • 56
  • 326
  • 368
Soner Gönül
  • 97,193
  • 102
  • 206
  • 364

7 Answers7

7

The contract for GetHashCode() requires it, but since anyone can make their own implementation it is never guaranteed.

Many classes (especially hashtables) require it in order to behave correctly.

If you are implementing a class, you should always make sure that two equal objects have the same hashcode.

If you are implementing an utility method/class, you can assume that two equal objects have the same hashcode (if not, it is the other class, not yours, that is buggy).

If you are implementing something with security implications, you cannot assume it.

Rasmus Faber
  • 48,631
  • 24
  • 141
  • 189
  • If `K.Equals(M)` but the values of `GetHashCode()` are different then the class is buggy and probably shouldn't be used anyway. – Paweł Obrok Aug 01 '11 at 13:29
2

If that's true, K and M always has the same HashCode ?

Yes.

Or rather it should be the case. Consumers of hash codes (eg. containers) can assume that equal objects have equal hash codes, or rather unequal hash codes means the objects are unequal. (Unequal objects can have the same hash code: there are more possible objects than hash codes so this has to be allowed.)

Or It depends on the programming language ?

No

Richard
  • 106,783
  • 21
  • 203
  • 265
1

Yes, it should return the same hash code.

I'd say it's language independent. But there's no guaranty as if other programmes has implemented that correctly.

GetHashCode returns a value based on the current instance that is suited for hashing algorithms and data structures such as a hash table. Two objects that are the same type and are equal must return the same hash code to ensure that instances of System.Collections.HashTable and System.Collections.Generic.Dictionary work correctly.

Johnny5
  • 6,664
  • 3
  • 45
  • 78
  • It doesn't must, but should.Sometimes different objects has the same hash and this is a case – sll Aug 01 '11 at 13:30
  • must or should ? sorry my english is sometimes bad... I'll edit my answer. But yes different objects may have the same hash code, but equals object should not have different hashcodes. – Johnny5 Aug 01 '11 at 13:39
1

If that's true, K and M always has the same HashCode ?

Yes. Unless they have a wickedly overridden Equals method. But that would be considered broken.

But note that the reverse is not true,
if K and M have the same HashCode it could still be that K.Equals(M) == false

H H
  • 263,252
  • 30
  • 330
  • 514
  • @Soner: No, that's another concept. HashCodes are allowed to collide, that doesn't fit a Set description. – H H Aug 01 '11 at 14:03
0

It depends on the Equals implementation of the object. It may use GetHashCode under the hood, but it doesn´t have too. So basically if you have an object with a custom Equals implementation the HashCode may be different for both objects.

Soner Gönül
  • 97,193
  • 102
  • 206
  • 364
Dominik
  • 3,342
  • 1
  • 17
  • 24
0

in your application the hashcode has to uniquely identify an instance of the object. this is part of to the .net platform, so, the hashcode value should work regardless of which .net language you are authoring in.

Jason
  • 15,915
  • 3
  • 48
  • 72
  • 1
    The hash code does not guarantee uniqueness in anyway. To steal and paraphrase a line from Eric Lippert, there are about 4 billion possible hash code results, there are an infinite number of possible objects such as strings. At best, hash codes thin the herd, but it is not expected to match one and only one object. – Anthony Pegram Aug 01 '11 at 14:06
0

GetHashCode() could return the same hash for different objects. You should use Equals() to compare objects not GetHashCode(), in case when GetHashCode() return the same value - implementation of Equals() should consider another object equality checks.

Hash data structure able to handle such cases by using collision resolution algotithms.

From wikipedia:

Hash collisions are practically unavoidable when hashing a random subset of a large set of possible keys. For example, if 2,500 keys are hashed into a million buckets, even with a perfectly uniform random distribution, according to the birthday problem there is a 95% chance of at least two of the keys being hashed to the same slot.

Therefore, most hash table implementations have some collision resolution strategy to handle such events. Some common strategies are described below. All these methods require that the keys (or pointers to them) be stored in the table, together with the associated values.

sll
  • 61,540
  • 22
  • 104
  • 156