Using structure as hashtable key

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am wondering if thereis a problem with using a structure (contains 2
strings and 1 datetime) as a key to a hashtable. I have created it without
overriding the gethashcode or equals functions and it seems to work. However
i am not sure if occasionally this can cause a problem with uniqueness. The
examples i ahve seen all use classes and override the two functions mentioned
above. I may make this change to a class but i want to be sure i am making a
gain by doing so. Thanks for any information on this.
 
I am trying to envision a good reason to use a multi-field struct (or a class
for that matter) for a key. The only I have come up with is you are matching
keys to a database table with a composite key. A bad reason I can think of to
do this is you desire to store two objects in the Hashtable at one time so
you can store more data. Understanding the what behind your question will
help.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Basically i have a list of data, in no real order with duplicates spread
within the list. The key to the list is the 3 fields. I need to group
together, sort, and seperate based upon the uniquesses of these 3 fields.
 
You want to override GetHashCode() only if you think it will improve the
performance of Hashtable's store/retrieve operations. AFAIK, There won't be
any problems with two classes having the same hash code, just inefficiency.

Search the web and read on how hash tables work inside out and how they use
hash codes and buckets.

-Oleg.
 
Have any good resources? Thanks.

Oleg Ogurok said:
You want to override GetHashCode() only if you think it will improve the
performance of Hashtable's store/retrieve operations. AFAIK, There won't be
any problems with two classes having the same hash code, just inefficiency.

Search the web and read on how hash tables work inside out and how they use
hash codes and buckets.

-Oleg.
Click to expand...
 
If you choose to override Equals and GetHashCode I recommend something
like the following.

public struct SomeStruct
{
public DateTime dateTime1;
public string string1;
public string string2;

public override bool Equals(object o)
{
if (o is SomeStruct)
{
SomeStruct s = (SomeStruct)o;
return
this.dateTime1 == s.dateTime1 &&
this.string1 == s.string1 &&
this.string2 == s.string2;
}
return false;
}

public override int GetHashCode()
{
// XOR'ing the constituent member's hash codes usually
// produces a fairly good distribution of values and it's
// fast and easy.
return
this.dateTime1.GetHashCode() ^
this.string1.GetHashCode() ^
this.string2.GetHashCode();
}
}

Brian
 
Brian Gideon said:
public override int GetHashCode()
{
// XOR'ing the constituent member's hash codes usually
// produces a fairly good distribution of values and it's
// fast and easy.
return
this.dateTime1.GetHashCode() ^
this.string1.GetHashCode() ^
this.string2.GetHashCode();
}
}
Click to expand...

XORing is a *bad* way of producing hashcodes. It means that the
hashcode of

dateTime1 = (whatever)
string1 = "foo"
string2 = "bar"

is the same as

dateTime1 = (the same whatever)
string1 = "bar"
string2 = "foo"

I tend to use the form outlined in Josh Bloch's excellent book
"Effective Java" (much of which can be applied to C#). It's
fundamentally:

int result = 17;
result = result*37 + dateTime1.GetHashCode();
result = result*37 + string1.GetHashCode();
result = result*37 + string2.GetHashCode();

(Obviously you don't need to do the first multiplication by 37, but it
gives the right flavour of the thing.)

He gives rather more information about it than I've got time to give
now - basically it's a *reasonable* hashcode without being brilliant.
 
Interesting. I guess I never thought about that case. Of course, it
seems so obvious now that you mention it.
 
Back
Top