Object.GetHashCode() Method

  • Thread starter Thread starter One Handed Man [ OHM# ]
  • Start date Start date
O

One Handed Man [ OHM# ]

The help for the .NET Framework Class Library tells us that the Object.GetHashCode() Method does not guarantee uniqueness' or consistency and that overriding this and the Equals method is a good idea.

It also tells us that using the XOR functions on two or more Fields or Properties is an acceptable way to achieve this.

What do you guys think is the best approach to this given that generating a hashcode should be fast as well as consistant.
 
OHM,
When I'm defining classes that I want to be "HashTable friendly" I do both
of what you quoted, the general template I follow is:

Public NotInheritable Class KeyPair

Private ReadOnly m_key1, m_key2 As Integer

Public Sub New(ByVal key1 As Integer, ByVal key2 As Integer)
m_key1 = key1
m_key2 = key2
End Sub

Public Overrides Function GetHashCode() As Integer
Return m_key1.GetHashCode() Xor m_key2.GetHashCode()
End Function

Public Overloads Function Equals(ByVal other As KeyPair) As Boolean
Return m_key1 = other.m_key1 AndAlso m_key2 = other.m_key2
End Function

Public Overloads Overrides Function Equals(ByVal obj As Object) As
Boolean
If TypeOf obj Is KeyPair Then
Return Me.Equals(DirectCast(obj, KeyPair))
Else
Return False
End If
End Function

End Class

Note that there may be more "key" fields, and there may be non "key" fields
also. Normally I make the "key" fields immutable (ReadOnly) to ensure that
the HashCode does not change causing problems for the HashTable itself. In a
couple cases I notify the container (HashTable) that a "key" is changing, so
that it can remove the old key and add the new key.

Remember that the HashCode gives the HashTable a slot to put the item into,
that the HashTable then uses the Equals function to see if the item is
already in that slot. In other words a single slot can have multiple items.
Also there are other "requirements" that make a good hash code, however I'm
taking it on faith that the primitive types return good hash codes. By
making my types build upon the primitive types, my types should also have
fairly good hash codes...

Hope this helps
Jay

"One Handed Man [ OHM# ]" <O_H_M{at}BTInternet{dot}com> wrote in message
The help for the .NET Framework Class Library tells us that the
Object.GetHashCode() Method does not guarantee uniqueness' or consistency
and that overriding this and the Equals method is a good idea.

It also tells us that using the XOR functions on two or more Fields or
Properties is an acceptable way to achieve this.

What do you guys think is the best approach to this given that generating a
hashcode should be fast as well as consistant.
 
Its a a little bit of a thorny subject. Many thanks for your reply which is
excellent as allways.

Regards - OHM

---------------
OHM,
When I'm defining classes that I want to be "HashTable friendly" I do
both of what you quoted, the general template I follow is:

Public NotInheritable Class KeyPair

Private ReadOnly m_key1, m_key2 As Integer

Public Sub New(ByVal key1 As Integer, ByVal key2 As Integer)
m_key1 = key1
m_key2 = key2
End Sub

Public Overrides Function GetHashCode() As Integer
Return m_key1.GetHashCode() Xor m_key2.GetHashCode()
End Function

Public Overloads Function Equals(ByVal other As KeyPair) As
Boolean Return m_key1 = other.m_key1 AndAlso m_key2 =
other.m_key2 End Function

Public Overloads Overrides Function Equals(ByVal obj As
Object) As Boolean
If TypeOf obj Is KeyPair Then
Return Me.Equals(DirectCast(obj, KeyPair))
Else
Return False
End If
End Function

End Class

Note that there may be more "key" fields, and there may be non "key"
fields also. Normally I make the "key" fields immutable (ReadOnly) to
ensure that the HashCode does not change causing problems for the
HashTable itself. In a couple cases I notify the container
(HashTable) that a "key" is changing, so that it can remove the old
key and add the new key.

Remember that the HashCode gives the HashTable a slot to put the item
into, that the HashTable then uses the Equals function to see if the
item is already in that slot. In other words a single slot can have
multiple items. Also there are other "requirements" that make a good
hash code, however I'm taking it on faith that the primitive types
return good hash codes. By making my types build upon the primitive
types, my types should also have fairly good hash codes...

Hope this helps
Jay

"One Handed Man [ OHM# ]" <O_H_M{at}BTInternet{dot}com> wrote in
message The help for the .NET Framework Class Library tells us that the
Object.GetHashCode() Method does not guarantee uniqueness' or
consistency and that overriding this and the Equals method is a good
idea.

It also tells us that using the XOR functions on two or more Fields or
Properties is an acceptable way to achieve this.

What do you guys think is the best approach to this given that
generating a hashcode should be fast as well as consistant.
 
Back
Top