IEqualityComparer <T> GetHashCode在项目不相等时返回相同的值？

Question

在用于该文档中的"对实施者的说明"部分中GetHashCode的方法的的IEqualityComparer<T>接口,它规定:

需要实现以确保如果Equals方法对于两个对象x和y返回true,则x的GetHashCode方法返回的值必须等于为y返回的值.

众所周知,为什么你希望两个实例T在两个项相等的情况下返回相同的哈希码; 他们不同意味着他们不平等,而他们是相同意味着他们可能是平等的.

当两个实例不相等时,我将引用解释为未定义的返回值(即使它们的值可能表示如此).

以下面的例子为例.我有一个序列int?我想用于统计分类,其中每个非null int?表示一个类的属性(想想枚举值).在这些值为空的情况下,您不希望将值视为相等,因为它们会将训练集偏向缺失值.如果有的话,在这种情况下,当与其他空值比较时,您将需要空值以返回false.

问题是,在GetHashCode方法中,当给出null时,我可能想要返回0(或者其他一些数字,也许Int32.MinValue).现在,我知道当使用此IEqualityComparer<T>实现键入任何内容时,检查字典中是否存在键的性能对于这些情况不是最佳的.

也就是说GetHashCode,当调用Equals返回false 时,返回已知冲突的值为其他值时是否有效？我倾向于是,因为上面的引用在这个问题上是不确定的.

Answer 1

这是绝对必要的,几乎所有的类型有是两个值v1,并v2使得

v1.Equals(v2) == false
v1.GetHashCode() == v2.GetHashCode()

......或等同于IEqualityComparer<T>.唯一不存在这种情况的情况是最多有2 ^32个不同(不相等)的值.只要有更多的值,pigeon-hole原则就会 强制重用哈希码 - 没有足够的哈希码可以绕过!

埃里克利珀有一个很大的散列码的博客文章,非常值得一读.基本上我认为你有正确的想法,但值得加强它们.

顺便说一句,空值的问题是一个有趣的问题.IEqualityComparer<T>允许GetHashCode抛出异常,但我相信内置的Comparer<T>实现永远不会.听起来你确实有一个问题 - 那Equals应该是反身的 - 所以空值应该等于它自己.你可能需要仔细考虑一下......你能代表"不同的"空值吗？