Hello Andreas,
Imho we should revert the change, especially as MS seems to also have an
implementation with low collisions (and in fact this will be what people are
expecting from a hashcode without any further explanation) we should do the
same. Otherwise this might drive some implementations
Hey,
With the recent talk on GetHashCode(), I was just taking a look at the code.
I decided to try my hand at seeing what would happen performancewise if i
made the function work with an int* as opposed to char*. Turns out i ended
up with something which was 50% slower, but also had 50% less
I have been asked to move this discussion to the e-mail list from IRC.
Basically we (my company and I) have new unit tests errors in 2.0
that did not occur at 1.9. The errors were traced to the
String.GetHashCode change. I had one of our interns (Mike) research
the change and I wanted to share
Hello,
Here are some data which hopefully bring some light to this topic. I
didn't measure uniqueness of hashcodes as I consider it less important
as range distribution. Enclosed you can find the result for you data
with old and new string.GetHashCode implementation.
Some numbers to look
Hi,
Where is this hashcode implementation taken from ? I don't think we
should invent new ones.
Zoltan
2008/7/17 Marek Safar [EMAIL PROTECTED]:
Hello,
Here are some data which hopefully bring some light to this topic. I didn't
measure uniqueness of
