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