c – 不确定unordered_map的工作原理

我有点困惑,unordered_map是如何工作的,什么是桶以及如何管理它们.

从this blog post开始,unordered_map是向量的向量.

我的问题是：

>假设桶是“内部”向量是正确的吗？
>因为每个桶(向量)可以包含多个元素,由哈希表上的哈希冲突(“外部”向量)给出,并且因为我们必须扫描这个内部向量(在线性时间内),所以假设我们必须在密钥类型上定义相等的方法(对哈希运算符成瘾)才能找到桶内的密钥？
>默认情况下外部向量(哈希表)大小是多少？
>默认情况下内部矢量大小是多少？
>如果一个桶中的元素数量变得太大会发生什么呢？换句话说,重新发生时会发生什么？

很抱歉这些问题,但我没有找到任何详细解释这个结构如何工作(例如在cppreference.com上).

解决方法

std::unordered_map是标准的C hash table.它曾经在STL中被称为 hash_map,但在1998年许多STL的接口被合并到C时错过了船,到2011年,很多图书馆都有自己的hash_map,C必须选择另一个名字(我认为“无序”是一个很好的选择;假设哈希表中的顺序是错误的常见来源).

is it correct to assume that the buckets are the “internal” vectors?

不,它都是不正确的(与迭代器无效要求不兼容)和危险(在这个假设下你最终可能会减去指向同一个桶中元素的指针).

在现实生活中,桶是链表;例如

> LLVM libc unordered_map是__hash_node的链接列表的unique_ptr to an array
> GNU libstdc unordered_map是_Hash_node的链接列表的pointer to an array

is it correct to assume that we have to define the equal method on the key type (in addiction to the hash operator) in order to find the key inside the bucket?

是的,在桶中定位密钥正是std :: unordered_map的第4个模板参数所针对的(当然,不需要在字面上调用“密钥类型上的相等方法”)

what is the external vector (hash table) size by default?

没有“外部载体”.默认构造的std :: unordered_map的桶数为implementation-defined,您可以使用bucket_count进行查询.

what is the internal vector size by default?

没有“内部载体”.任何给定存储桶的大小等于当前放置在存储桶中的元素数.您可以使用bucket_size查询它

what happens if the number of elements in one bucket becomes too big?bor in other words,when the rehash happens?

如果一个桶中的元素数量变得太大,则没有任何反应.但如果每个桶的平均元素数量(即load_factor)超过max_load_factor,则重新发生(例如insert)