Using structure as hashtable key

[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.

 

[Guest]

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!
***************************

 

[Guest]

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.

 

[Oleg Ogurok]

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.

 

[Guest]

Have any good resources? Thanks.

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.

 

[Brian Gideon]

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

 

[Oleg Ogurok]

Yep. Just google for "hash table"
http://www.google.com/search?hl=en&q=hash+tables
This one looks good:
http://www.sparknotes.com/cs/searching/hashtables/section1.html
or
http://burtleburtle.net/bob/hash/evahash.html

Hash tables are not especially easy to understand, but once you do, it'll
pay in the long run.
I was fortunate to learn about them in college.

-Oleg.

 

[Jon Skeet [C# MVP]]

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();
}
}

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.

 

[Brian Gideon]

Interesting. I guess I never thought about that case. Of course, it
seems so obvious now that you mention it.