最近unordered_map在C++中的讨论使我意识到,我应该使用之前使用unordered_map过的大多数情况map,因为查找的效率(摊销的O(1)与O(log n)).大多数时候我使用的地图我使用int或std::string作为键,因此我对哈希函数的定义没有任何问题.我越是想到它,我就越发现我发现std::map在一个简单类型的情况下我找不到任何理由std::unordered_map- 我看了一下界面,并没有发现任何显着的差异会影响我的代码.
因此,这个问题-有没有使用任何真正的原因std::map在std::unordered map简单类型一样的情况下,int和std::string？
我从一个严格的编程角度问我 - 我知道它没有被完全认为是标准的,并且它可能会带来移植问题.
另外我希望正确的答案之一可能是"它对于较小的数据集更有效",因为开销较小(是真的吗？) - 因此我想将问题限制在密钥数量的情况下是非平凡的(> 1 024).
编辑: 呃,我忘记了显而易见的(感谢GMan!) - 是的,地图是当然有序的 - 我知道,我正在寻找其他原因.
c ++ unordered_map碰撞处理,调整大小和重新散列
这是我之前提出的一个问题,我看到我对unordered_map的实现方式感到很困惑.我相信很多其他人都会和我分享这种困惑.基于我所知道的信息而不阅读标准:
每个unordered_map实现都将链表存储到存储桶数组中的外部节点...不,这对于实现最常见用途的哈希映射来说并不是最有效的方法.不幸的是,unordered_map规范中的一个小"疏忽"都需要这种行为.所需的行为是元素的迭代器在插入或删除其他元素时必须保持有效
我希望有人可以解释实现以及它如何与c ++标准定义(在性能要求方面)相对应,以及它是否真的不是实现哈希映射数据结构的最有效方法如何改进它？