为什么不区分大小写的std :: hash函数用于std :: unordered_set?

时间:2017-04-09 06:43:02

标签: c++ c++11 unordered-set

我的问题不是关于使用不区分大小写的std :: unordered_set,而是它是如何工作的?

#include "stdafx.h"
#include <string>
#include <iostream>
#include <unordered_set>
#include "boost/algorithm/string.hpp"


struct case_insensitive_comparer
{
    bool operator () (const std::string& x, const std::string& y) const
    {
        return boost::iequals(x, y);
    }
};

using case_insensitive_set = std::unordered_set<std::string, std::hash<std::string>, case_insensitive_comparer>;

std::vector<std::string> permute_case(const std::string& s)
{
    std::vector<std::string> strs;

    // Iterate through all bitmasks, 1 for uppercase, 0 for lowercase
    int msb = 1 << (s.length() - 1);
    int upper = 1 << s.length();
    std::locale loc;
    for (int i = 0; i < upper; i++)
    {
        int bit = msb;
        std::string current = "";
        for (size_t j = 0; j < s.length(); j++, bit >>= 1)
            current += (bit & i) ? std::toupper(s[j], loc) : std::tolower(s[j], loc);

        strs.push_back(current);
    }

    return strs;
}

int main()
{
    std::vector<std::string> strs = permute_case("awesome");

    case_insensitive_set set(strs.begin(), strs.end());

    // Check the hash
    for (auto& s : strs)
        std::cout << s << " :" << std::hash<std::string>()(s) << "\n";

    // Check the element
    for (auto& s : set)
        std::cout << s << "\n";

    return 0;
}

所以我使用字符串不区分大小写的比较器std::unordered_setstd::hash<std::string>作为哈希函数。我对哈希集的基本理解(我假设unordered_set就像一个哈希集)是它计算密钥的哈希并将其放入集合中(如果它还不存在)。并且比较器Pred用于当集合试图插入密钥并且存在哈希冲突时,它必须确定密钥是相同还是不同。

基于代码,它无论如何都有效,因此我的一些假设是不正确的。如果有人告诉我哪些假设是错误的,那会很有帮助。

谢谢。

编辑:我对这种不区分大小写的unordered_set的期望是,应该只插入1个密钥,这是我观察到的情况,即只显示了真棒。所以对于我的情况,我认为它有效,但真的来自kennytm的回答,我很幸运得到所有的钥匙都在同一个桶里。我确实使用MSVC来编译代码。

2 个答案:

答案 0 :(得分:3)

问题是你有一个区分大小写的哈希和一个不区分大小写的比较器。如果你使hasher case不敏感,那么你将只得到一个条目。

例如:

#include <boost/algorithm/string/case_conv.hpp>

struct case_insensitive_hasher
{
  size_t operator()(const std::string& key) const
    {
      std::string keyCopy(key);
      boost::to_lower(keyCopy);
        return std::hash<std::string>()(keyCopy);
    }
};

using case_insensitive_set = std::unordered_set<std::string, case_insensitive_hasher, case_insensitive_comparer>;

输出将包含AWESOME,插入第一个条目。

答案 1 :(得分:2)

让我们回想一下hash table是如何运作的。

  1. 容量 N 的哈希表是一个桶数组。存储桶通常是链表或二叉搜索树。从概念上讲,您可能会将哈希表视为

    template <typename T>
    class HashTable {
        std::vector<std::forward_list<T>> _buckets;
    
    public:
        HashTable(size_t capacity = 16) : _buckets(capacity) {}
        size_t bucket_count() const { return _buckets.size(); }
    
  2. 每个键 k ∈T可以插入到哈希表的桶中。选择哪个存储桶由函数bucket_index确定,该函数将 k 的容量 N 作为输入,并生成数组索引0≤ i &lt; N ,该密钥属于哪个桶。

        void insert(T&& key) {
            // locate the bucket.
            size_t i = bucket_index(key, bucket_count());
            auto& bucket = _buckets[i];
            // ensure the key does not already exist in the bucket
            if (std::find(bucket.cbegin(), bucket.cend(), key) == bucket.cend()) {
                // now insert the key into the bucket.
                bucket.push_front(std::move(key));
            }
        }
    
  3. bucket_index函数通常根据哈希函数实现,然后将模数与容量一起使用:

    private:
        static size_t bucket_index(const T& key, size_t cap) {
            return std::hash<T>()(key) % cap;
        }
    };
    

    请注意,它不直接使用std::hash<T>()(key):只要hash % cap相等,两个键就会引用同一个存储桶。

  4. 这就是OP的代码似乎适用于MSVC的原因。在MSVC的unordered_set实施中,初始容量为8。然后,如果您print the hash as hexadecimal,您会注意到最后一个数字始终为c

    AWESOME :7552acc94fd16a5c
    AWESOMe :75528cc94fd133fc
    AWESOmE :75bf6cc9502dcf7c
    AWESOme :75bf8cc9502e05dc
    AWESoME :60234cc8b2d194fc
    ...
    awesOme :976734d757ba79dc
    awesoME :81caf4d6ba5e08fc
    awesoMe :81cb14d6ba5e3f5c
    awesomE :815e34d6ba01a3dc
    awesome :815e14d6ba016d7c
    

    因此,hash % 8将始终为4,即所有128个密钥都将选择八个中的相同存储桶。还记得我们选择一个水桶后会发生什么吗?我们检查一个密钥是否已经存在于链表中,这一直是真的,所以只有第一个密钥&#34; AWESOME&#34;将出席。

    AWESOME
    

    这给出了仅仅替换==的错觉,而真正发生的只是 MSVC的哈希函数质量非常差

    为了进一步表明OP的代码&#34;不起作用,让我们切换到另一个标准库。当使用clang和libc ++时,我们得到以下结果:

    AWESOME :1a285ecfc4bab378
    AWESOMe :acb9b7f4f69b16e2
    AWESOmE :fd66d9186a434601
    AWESOme :254b008bd66d1e29
    AWESoME :27cac8154bb934d0
    ...
    awesOme :a4e8c2140834341e
    awesoME :cfd12a83da4a4b0f
    awesoMe :b4c4eb4c60968581
    awesomE :bdca27cd606f4f42
    awesome :14ddc089ab5badb5
    

    与MSVC的哈希不同,libc ++的哈希是非常均匀分布的。 libc ++的unordered_set的初始容量为2,两个桶都被填充,因此该集合有两个元素:

    AWESOmE
    AWESOME
    

    和OP的代码一般不起作用。

    注意:这里我假设哈希冲突由单独的链接处理,并且没有动态调整大小,尽管这两个都不会进入图片,因为==总是返回true