//+------------------------------------------------------------------+//| Adds the specified key and value to the map. |//+------------------------------------------------------------------+template<typename TKey,typename TValue>
bool CHashMap::Add(TKey key,TValue value);
//+------------------------------------------------------------------+//| Gets the value associated with the specified key. |//+------------------------------------------------------------------+template<typename TKey,typename TValue>
bool CHashMap::TryGetValue(TKey key,TValue &value);
几乎是不可能的，如果你碰到了，访问仍然是超级有效的。
在任何效率水平上的碰撞都是不好的。谢谢你的答复。我会牢记这一点。
在任何效率水平上的碰撞都是不好的。谢谢你的答复。我会牢记这一点。
根据定义，哈希图不是无碰撞的。
关于碰撞的问题。在这种情况下，有可能遇到碰撞吗？
如果已经制作了27000份记录。
你会不断得到碰撞，特别是当集合增长（调整大小）时。由于哈希值被额外地截断为帮派号码，而它们的数量总是有限的（理想情况下等于1）。
结论。
1.对地图来说，重要的不是哈希函数的密码学稳定性，而是它的速度。哈希函数只需要提供一个良好的随机性，就可以了。
2.最好通过各种手段避免调整大小。导致主要缩减的是尺寸的调整，而不是哈希函数的碰撞。只要有可能，总是用一个预设的项目数来初始化集合。即使你不确切知道它们，也要给出一个大概的数字--这将大大有助于算法。
3.碰撞是一种常规的压实机制。通过碰撞，有可能将三条id为159、4'569'209、29'459'876的记录存储在长度为3的数组中，而不是长度为30 000 000的数组中，即使最后两个值都落入索引为2的帮组中。
2.最好通过各种方式避免调整大小。主要的缺点是调整大小，而不是哈希函数的碰撞。只要有可能，就用一个预设的项目数来初始化这个集合。即 使你不确切知道它们，也要给出一个大概的数字--这对算法会有很大帮助。
请以实例说明。
到目前为止，我只使用这个。
请给我看一个例子。
到目前为止，我只使用这个。
当你创建一个CHashMap集合时，使用其中一个接受容量参数的构造函数。关于调整大小时的性能细节，请看我关于CDicionary的文章。对这种算法有一个完整的演练。
我在CHashMap中发现了一个非常不寻常的行为。
看来，据说添加了一个钥匙，但无法从中读取任何东西。然而，只要我再次添加钥匙，它就变得可读了！这时，我就会发现，在我的电脑上，有很多东西都是可读的。
这是一个BAG吗？
如果你把例子中的价格1.75141 换成另一个价格，它就会正常工作。
在没有调试的情况下，要在庞大的代码中发现这种行为，并创造这样一个简明的例子，简直是地狱般的困难。
只要有可能，总是用预先确定的元素数量来初始化集合。即使你不确切知道它们，也要给出一个大概的数字--这对算法会有很大帮助。
在上面的例子中，我试图通过构造函数来设置容量。从一定的容量值开始，该例子开始正常工作。
但我认为这是一个巧合。
我在CHashMap中发现了一个非常不寻常的行为。
看来，据说添加了一个钥匙，但无法从中读取任何东西。然而，只要再次添加钥匙，它就变得可读了！这就是为什么我们要把它称为 "可读"。
这是一个BAG吗？
如果你把例子中的价格1.75141 换成另一个价格，它就会正常工作。
在没有调试的情况下，要在庞大的代码中发现这种行为，并创造这样一个简明的例子，简直是地狱般的困难。
已纠正，将在今天的版本中出现。
谢谢你!我看到了编辑。
在上面的例子中，我试图通过构造函数来设置容量。从一定的容量值开始，该例子开始正常工作。
但我认为这是一个巧合。
是的，有一个又一个的小故障。我强烈建议不要使用Generic。