為什么 C++ STL hash 表（unordered_map）不接受向量作為鍵

Question

我認為這種設計選擇背后是有原因的。 Boost 似乎有一個實現，因此應該可以使用向量作為 hash 表鍵。 應用於 arrays 的 hash 函數是否有任何理論特性，使它們更容易發生碰撞或其他不良行為？

Answer 1

您會注意到 Boost 實際上並沒有擴展來專門接受vector<T>作為鍵 - 相反，它具有允許您使用任何Iterable的擴展 - 並且它僅生成 hash 作為 Iterable 內容的 function。 ..

這可能是可取的，也可能不是可取的，具體取決於：

• 如果您想使用對象身份而不是對象值作為散列的基礎......或者不。
• 如果您對散列作為非恆定時間操作感到滿意......或者不是。
  • 僅僅因為boost::hash_range看起來是O(n)並不意味着底層的迭代不需要 5 分鍾來返回每個調用的所有可散列值......
• 如果元素的順序確實 - 或無關緊要。
  • （我相信）將boost::hash_range或boost::hash_combine與兩個不同但等效的unordered_set對象之一一起使用將導致不同的哈希碼，盡管它們的值等價。
• 如果可以迭代相同值的兩個概念上不同的對象（例如，表示數據緩沖區的vector<uint8_t> ，或queue<SomeEnum>其中SomeEnum: uint8_t表示值隊列）應該具有相同的 hahs 代碼...或不是。

我懷疑STL 背后的團隊不喜歡上面描述的這么多上下文“如果”，這意味着提供默認行為是不明智的，因此他們要求您始終更明確地使用您的哈希- 生成任意對象（此外，如果您想要 Boost 的行為，那么首先使用 Boost - 這不像 Boost 正在與 STL 競爭）。

另請參閱此 QA： C++ unordered_map 使用自定義 class 類型作為鍵