很明显，这两个头文件分别是map、set头文件对应的unordered版本。 所以它们有一个重要的性质就是：
乱序
这个unorder暗示着，这两个头文件中类的底层实现----Hash。 也是因为如此，你才可以在声明这些unordered模版类的时候，传入一个自定义的哈希函数，准确的说是哈希函数子（hash function object）。
具有相同相同哈希值的元素被放在同一个桶（bucket）中。
在提供映射、集合功能的情况下，侧重于元素的快速获取。
用树结构（红黑树、二叉搜索树等）实现的map、set，在查找、获取、修改元素的时候，通常需要从根结点自上而下一次遍历树结构，因此时间复杂度为线性 ； 而通过哈希表实现， 只要哈希函数以及桶的大小选取得当，时间复杂度会是常数（只需要调用一次函数，并进行小幅度的查找）。
哈希表的实现复杂了该容器上的双向遍历，似乎没有一种合适的方法能够做到高效快速。 因此，unorder版本的map和set只提供前向迭代器（非unorder版本提供双向迭代器）。
lower_bound
upper_bound
普通版本的map和set，它们是有序容器，对每一个元素都能都能判断它应该在哪个之前、在哪个之后； 而该版本的容器则不一样，因为它们是乱序的，不能确定每个元素的先后顺序。 因此，容器没有足够的信息来计算这两个边界（然而元素的相等性比较依旧是可行的）。
出于实现的概念，该版本的类模版必不可少的多了些特殊的函数。
bucket_count ： 桶数量。
max_bucket_count ： 最大桶数量。
bucket_size ： 桶大小，即容量。
bucket ： 定位给定元素的桶位置。
load_factor ： 返回load factor，即容器当前元素数量与桶数量之比。
max_load_factor ： 返回或设置最大load factor。
rehash ： 设置桶的数量，并重新对元素进行哈希映射。
reserve ： 请求保留桶的数量至给定值。
注意到，没有函数能改变桶的容量，可能桶也是动态增长的。
hash_function : 返回哈希函数（在声明时作为参数传入，或默认的位于funtional头文件中的hash）。
key_eq : 返回key的相等性谓词，情况与hash_function相似。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
