Re: hashcode values
<Wizumwalt@gmail.com> wrote in message
news:1149713091.178434.320540@y43g2000cwc.googlegroups.com...
I was confused if the string's hashcode was always the same because I
run across posts saying that this is not always true. Maybe I'm
misunderstanding something there. I will go back and look.
Make sure you read Bjorn's post. It looks like you've misunderstood how
HashTable works.
That being said, two strings with equal contents will have equal
hashcodes. The algorithm for calculating hashcodes of strings is publicly
documented in the String class's API, and it is:
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
where s[i] is the ith character in the string, and n is the length of
the string.
The way I create the strings to get a hashcode, I'm certain that only a
single unique combination of the contents of a string exist in the
hashtable, so I don't believe there's any overlap there.
You will overwrite data if two of the strings you use coincidentally
happen to have the same hashcode.
Besides, a
Hashtable won't allow multiple same keys IIRC.
That's correct, which is why the data overwriting mentioned above will
occur.
And because I need speed in my lookups, I thought a hash code was
quicker than the contents of a string object.
It's slower, because HashTable does hashing internally. So instead of
hashing just once, there's two hashing going on: Once manually by you, and
once by the HashTable. Either way, premature optimization is bad. Don't
optimize until you actually have a performance problem. And profile your
code; don't just guess where to optimize.
As far as the new is concerned, well, I guess I could keep that off.
Not too well versed w/ new and just assigning a "". Maybe it's faster
to just assign.
Usually it's safer to "just assign". Using the constructor has different
semantics than using a String literal. Depending on which you use, your
program will behave differently.
- Oliver