unordered_map 真的是无序的吗？

Question

我对“unordered_map”这个名字感到很困惑。顾名思义，键根本没有排序。但我一直认为它们是按哈希值排序的。还是说错了（因为名字暗示它们不是有序的）？

或者换个说法：这是这个

typedef map<K, V, HashComp<K> > HashMap;

与

template<typename T>
struct HashComp {
    bool operator<(const T& v1, const T& v2) const {
        return hash<T>()(v1) < hash<T>()(v2);
    }
};

同

typedef unordered_map<K, V> HashMap;

？ （好吧，不完全是，STL 会在这里抱怨，因为可能有键 k1，k2 并且既不是 k1 multimap 并覆盖相等检查。）

或者再次不同：当我遍历它们时，我可以假设键列表是按它们的哈希值排序的吗？

Answer 1

在回答您编辑的问题时，这两个 sn-ps 根本不等效。 std::map 将节点存储在树结构中，unordered_map 将它们存储在哈希表中*。

键不按其“哈希值”的顺序存储，因为它们根本不按任何顺序存储。相反，它们存储在“桶”中，其中每个桶对应于一系列哈希值。基本上，实现是这样的：

function add_value(object key, object value) {
   int hash = key.getHash();

   int bucket_index = hash % NUM_BUCKETS;
   if (buckets[bucket_index] == null) {
       buckets[bucket_index] = new linked_list();
   }
   buckets[bucket_index].add(new key_value(key, value));
}

function get_value(object key) {
   int hash = key.getHash();

   int bucket_index = hash % NUM_BUCKETS;
   if (buckets[bucket_index] == null) {
       return null;
   }

   foreach(key_value kv in buckets[bucket_index]) {
       if (kv.key == key) {
           return kv.value;
       }
   }
}

显然这是一个严重的简化，实际实现会更先进（例如，支持调整 buckets 数组的大小，可能使用树结构而不是链表作为存储桶，等等），但这应该给出关于如何无法以任何特定顺序取回值的想法。请参阅wikipedia 了解更多信息。

* 从技术上讲，std::map 和 unordered_map 的内部实现是实现定义的，但该标准要求暗示这些内部实现的操作具有一定的 Big-O 复杂性

Answer 2

“无序”并不意味着在实现中某处没有线性序列。它的意思是“你不能假设这些元素的顺序”。

例如，人们经常假设条目会按照它们被放入的顺序从哈希映射中出来。但事实并非如此，因为条目是无序的。

至于“按其哈希值排序”：哈希值一般取自整数范围，但哈希映射中没有 2**32 个槽位。哈希值的范围将通过取模槽数来减少到槽数。此外，当您向哈希映射添加条目时，它可能会更改大小以适应新值。这可能会导致所有先前的条目被重新放置，从而改变它们的顺序。

在无序的数据结构中，您不能假设条目的顺序。

Answer 3

正如 unordered_map 的名字所暗示的，C++0x 标准没有指定排序。 unordered_map 的表观顺序取决于实际实现的方便程度。

Answer 4

如果您想进行类比，请查看您选择的 RDBMS。

如果您在执行查询时没有指定 ORDER BY 子句，则返回的结果是“无序的”——也就是说，按照数据库感觉的任何顺序。没有指定顺序，系统可以随意“订购”它们以获得最佳性能。

Answer 5

你是对的，unordered_map 实际上是哈希排序的。请注意，大多数当前实现（TR1 之前）将其称为 hash_map。

IBM C/C++ 编译器documentation 指出，如果您有一个最佳散列函数，那么在查找、插入和删除任意元素期间执行的操作数不依赖于其中的元素数。序列，所以这意味着顺序不是那么无序......

现在，散列排序是什么意思？由于哈希应该是不可预测的，根据定义，您不能对地图中元素的顺序做出任何假设。这就是它在 TR1 中重新命名的原因：旧名称暗示了一个订单。现在我们知道实际使用了一个订单，但您可以忽略它，因为它是不可预测的。