Loading docs/lang/csl/unordered-container.md +5 −5 Original line number Diff line number Diff line Loading @@ -2,20 +2,20 @@ 自 C++11 标准起,四种基于哈希实现的无序关联式容器正式纳入了 C++ 的标准模板库中,分别是: `unordered_set` , `unordered_multiset` , `unordered_map` , `unordered_multimap` 。 它们与相应的关联式容器在功能,函数等方面有诸多共同点,而最大的不同点则体现在普通的关联式容器一般采用红黑树实现,内部元素按特定顺序进行排序;而这几种无序关联式容器则采用哈希方式存储元素,内部元素不以任何特定顺序进行排序。 它们与相应的关联式容器在功能,函数等方面有诸多共同点,而最大的不同点则体现在普通的关联式容器一般采用红黑树实现,内部元素按特定顺序进行排序;而这几种无序关联式容器则采用哈希方式存储元素,内部元素不以任何特定顺序进行排序,所以访问无序关联式容器中的元素时,访问顺序也没有任何保证。 采用哈希存储的特点使得无序关联式容器 **在平均情况下** 大多数操作(包括查找,插入,删除)都能在常数时间复杂度内完成,相较于关联式容器与容器大小成对数的时间复杂度更加优秀。 !!! warning **在最坏情况下,对无序关联式容器的操作时间复杂度会与容器大小成线性!** 这一情况往往在容器内出现大量哈希冲突时产生,因此在不保证数据随机的场合应谨慎使用无序关联式容器存储数据。 在最坏情况下,对无序关联式容器进行插入、删除、查找等操作的时间复杂度会 **与容器大小成线性关系** !这一情况往往在容器内出现大量哈希冲突时产生,因此应谨慎使用无序关联式容器。 由于无序关联式容器与相应的关联式容器在用途和操作中有很多共同点,这里不再介绍无序关联式容器的各种操作,这些内容读者可以参考 [OI-wiki](./associative-container.md) 的介绍。 由于无序关联式容器与相应的关联式容器在用途和操作中有很多共同点,这里不再介绍无序关联式容器的各种操作,这些内容读者可以参考 [关联式容器](./associative-container.md)。 ## 制造哈希冲突 之前就已经提到过,在最坏情况下,对无序关联式容器的操作时间复杂度会与容器大小成线性。 上文中提到了,在最坏情况下,对无序关联式容器进行一些操作的时间复杂度会与容器大小成线性关系。 在哈希函数确定的情况下,很容易构造出数据使得容器内产生大量哈希冲突,导致复杂度达到上界。 在哈希函数确定的情况下,可以构造出数据使得容器内产生大量哈希冲突,导致复杂度达到上界。 在标准库实现里,每个元素的散列值是将值对一个质数取模得到的,更具体地说,是 [这个列表](https://github.com/gcc-mirror/gcc/blob/gcc-8_1_0-release/libstdc++-v3/src/shared/hashtable-aux.cc) 中的质数(g++ 6 及以前版本的编译器,这个质数一般是 $126271$,g++ 7 及之后版本的编译器,这个质数一般是 $107897$)。 Loading Loading
docs/lang/csl/unordered-container.md +5 −5 Original line number Diff line number Diff line Loading @@ -2,20 +2,20 @@ 自 C++11 标准起,四种基于哈希实现的无序关联式容器正式纳入了 C++ 的标准模板库中,分别是: `unordered_set` , `unordered_multiset` , `unordered_map` , `unordered_multimap` 。 它们与相应的关联式容器在功能,函数等方面有诸多共同点,而最大的不同点则体现在普通的关联式容器一般采用红黑树实现,内部元素按特定顺序进行排序;而这几种无序关联式容器则采用哈希方式存储元素,内部元素不以任何特定顺序进行排序。 它们与相应的关联式容器在功能,函数等方面有诸多共同点,而最大的不同点则体现在普通的关联式容器一般采用红黑树实现,内部元素按特定顺序进行排序;而这几种无序关联式容器则采用哈希方式存储元素,内部元素不以任何特定顺序进行排序,所以访问无序关联式容器中的元素时,访问顺序也没有任何保证。 采用哈希存储的特点使得无序关联式容器 **在平均情况下** 大多数操作(包括查找,插入,删除)都能在常数时间复杂度内完成,相较于关联式容器与容器大小成对数的时间复杂度更加优秀。 !!! warning **在最坏情况下,对无序关联式容器的操作时间复杂度会与容器大小成线性!** 这一情况往往在容器内出现大量哈希冲突时产生,因此在不保证数据随机的场合应谨慎使用无序关联式容器存储数据。 在最坏情况下,对无序关联式容器进行插入、删除、查找等操作的时间复杂度会 **与容器大小成线性关系** !这一情况往往在容器内出现大量哈希冲突时产生,因此应谨慎使用无序关联式容器。 由于无序关联式容器与相应的关联式容器在用途和操作中有很多共同点,这里不再介绍无序关联式容器的各种操作,这些内容读者可以参考 [OI-wiki](./associative-container.md) 的介绍。 由于无序关联式容器与相应的关联式容器在用途和操作中有很多共同点,这里不再介绍无序关联式容器的各种操作,这些内容读者可以参考 [关联式容器](./associative-container.md)。 ## 制造哈希冲突 之前就已经提到过,在最坏情况下,对无序关联式容器的操作时间复杂度会与容器大小成线性。 上文中提到了,在最坏情况下,对无序关联式容器进行一些操作的时间复杂度会与容器大小成线性关系。 在哈希函数确定的情况下,很容易构造出数据使得容器内产生大量哈希冲突,导致复杂度达到上界。 在哈希函数确定的情况下,可以构造出数据使得容器内产生大量哈希冲突,导致复杂度达到上界。 在标准库实现里,每个元素的散列值是将值对一个质数取模得到的,更具体地说,是 [这个列表](https://github.com/gcc-mirror/gcc/blob/gcc-8_1_0-release/libstdc++-v3/src/shared/hashtable-aux.cc) 中的质数(g++ 6 及以前版本的编译器,这个质数一般是 $126271$,g++ 7 及之后版本的编译器,这个质数一般是 $107897$)。 Loading