unordered_map 迭代器/引用失效是否允许布谷鸟、跳房子和罗宾汉散列?

Phi*_*ler 5 c++ unordered-map hashtable language-lawyer c++14

我试图弄清楚是否有可能std::unordered_map使用 Cuckoo Hashing、Hopscotch Hashing 和 Robin Hood Hashing 等技术构建现代 C++ 的合规、高效实现,这些技术允许非常紧凑的表、高负载因子并保持高性能。这些技术的特别之处在于,它们涉及潜在地移动一些元素来为其他元素腾出空间,而不仅仅是链接或探测直到找到一个开放的插槽(如在线性或二次探测中)或。

来自insert http://www.cplusplus.com/reference/unordered_map/unordered_map/insert/

  1. 迭代器有效性在大多数情况下,容器中的所有迭代器在插入后仍然有效。唯一的例外是当容器的增长迫使重新散列时。在这种情况下,容器中的所有迭代器都将失效。

  2. 如果插入操作后新容器的大小增加到超过其容量阈值(计算为容器的 bucket_count 乘以其 max_load_factor),则强制重新散列。

  3. 对 unordered_map 容器中元素的引用在所有情况下都保持有效,即使在重新哈希后也是如此。

而对于erase http://www.cplusplus.com/reference/unordered_map/unordered_map/erase/

  1. 只有迭代器和对被删除元素的引用无效。

  2. 其余不受影响。

  3. [仅限 c++14] 保留未由操作删除的元素的相对迭代顺序。

其他引用在这两个操作中通常保持有效的要求似乎需要一个涉及驱逐的探测方案来处理表结构,该表结构将分配的节点与数组分开并指向它们。也许实现可以保留一个单独的元素数组,表中的条目可以索引到这些元素,以避免额外的动态分配,但这仍然增加了额外的间接性。有没有更有效的方法来满足这个要求?

insert即使在重新散列之后,元素引用仍然有效的要求似乎意味着即使对于链接或非移动开放寻址设计,也需要动态节点分配或类似上述间接数组的东西。那正确吗?

一般来说,标准所提出的要求是否unordered_map强制执行间接或哈希表实现中的其他某种低效率?