blocks|key|4368789|text|我用Dan+Bernstein的djb2得到了很好的结果。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4368790|unsigned+long
hash(unsigned+char+*str)
{
++++unsigned+long+hash+=+5381;
++++int+c;

++++while+(c+=+*str%2B%2B)
++++++++hash+=+((hash+<<+5)+%2B+hash)+%2B+c;+/*+hash+*+33+%2B+c+*/

++++return+hash;
}|code-block|syntax|javascript|4368791|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cse.yorku.ca/~oz/hash.html^0|G|4|G|4|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@$9|V|A|W|1|X]]|E|$]]|$1|F|3|G|5|H|7|Y|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|L|$M|$5|N|O|P|E|$Q|R]]]]

I've had nice results with <a href="http://www.cse.yorku.ca/~oz/hash.html"><code>djb2</code></a> by Dan Bernstein.

<pre><code>unsigned long
hash(unsigned char *str)
{
 unsigned long hash = 5381;
 int c;

 while (c = *str++)
 hash = ((hash &lt;&lt; 5) + hash) + c; /* hash * 33 + c */

 return hash;
}
</code></pre>

blocks|key|609201|text|首先，将130个单词的40个冲突散列为0..99是不好的吗？如果您没有采取专门的步骤来实现哈希，就不能期望完美的哈希。在大多数情况下，普通哈希函数的冲突不会比随机生成器少。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|609202|具有良好声誉的散列函数是MurmurHash3。|offset|length|609203|最后，关于哈希表的大小，它实际上取决于您考虑的哈希表的类型，特别是，存储桶是可扩展的还是单槽的。如果存储桶是可扩展的，那么还有一个选择:您可以为内存/速度约束选择平均存储桶长度。|609204|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/smhasher/wiki/MurmurHash3^0|0|C|B|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

First, is 40 collisions for 130 words hashed to 0..99 bad? You can't expect perfect hashing if you are not taking steps specifically for it to happen. An ordinary hash function won't have fewer collisions than a random generator most of the time.

A hash function with a good reputation is <a href="http://code.google.com/p/smhasher/wiki/MurmurHash3" rel="nofollow">MurmurHash3</a>.

Finally, regarding the size of the hash table, it really depends what kind of hash table you have in mind, especially, whether buckets are extensible or one-slot. If buckets are extensible, again there is a choice: you choose the average bucket length for the memory/speed constraints that you have.

blocks|key|2753534|text|首先，您通常不希望对哈希表使用加密哈希。一种算法在密码标准上是非常快的，但是在哈希表标准上仍然慢得令人痛苦。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2753535|其次，您希望确保输入的每一位都可以/将影响结果。一种简单的方法是将当前结果旋转一定数量的位，然后将当前哈希码与当前字节进行异或。重复此操作，直到到达字符串的末尾。请注意，您通常也不希望旋转为字节大小的偶数倍。|2753536|例如，假设常见的情况是8位字节，您可以旋转5位：|2753537|int+hash(char+const+*input)+{+
++++int+result+=+0x55555555;

++++while+(*input)+{+
++++++++result+%5E=+*input%2B%2B;
++++++++result+=+rol(result,+5);
++++}
}|code-block|syntax|javascript|2753538|编辑:还要注意，对于哈希表大小来说，10000个槽很少是一个好的选择。您通常需要两种情况中的一种:要么需要一个质数作为大小(对于某些类型的散列解析来说，这是确保正确性所必需的)，要么就是2的幂(因此可以使用简单的位掩码将值减小到正确的范围)。|2753539|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|R|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

First, you generally do not want to use a cryptographic hash for a hash table. An algorithm that's very fast by cryptographic standards is still excruciatingly slow by hash table standards.

Second, you want to ensure that every bit of the input can/will affect the result. One easy way to do that is to rotate the current result by some number of bits, then XOR the current hash code with the current byte. Repeat until you reach the end of the string. Note that you generally do not want the rotation to be an even multiple of the byte size either.

For example, assuming the common case of 8 bit bytes, you might rotate by 5 bits:

<pre><code>int hash(char const *input) { 
 int result = 0x55555555;

 while (*input) { 
 result ^= *input++;
 result = rol(result, 5);
 }
}
</code></pre>

Edit: Also note that 10000 slots is rarely a good choice for a hash table size. You usually want one of two things: you either want a prime number as the size (required to ensure correctness with some types of hash resolution) or else a power of 2 (so reducing the value to the correct range can be done with a simple bit-mask).

blocks|key|606861|text|Wikipedia+shows一个很好的字符串散列函数，叫做Jenkins，每次一个散列。它还引用了这个散列的改进版本。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|606862|uint32_t+jenkins_one_at_a_time_hash(char+*key,+size_t+len)
{
++++uint32_t+hash,+i;
++++for(hash+=+i+=+0;+i+<+len;+%2B%2Bi)
++++{
++++++++hash+%2B=+key[i];
++++++++hash+%2B=+(hash+<<+10);
++++++++hash+%5E=+(hash+>>+6);
++++}
++++hash+%2B=+(hash+<<+3);
++++hash+%5E=+(hash+>>+11);
++++hash+%2B=+(hash+<<+15);
++++return+hash;
}|code-block|syntax|javascript|606863|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Jenkins_hash_function^0|0|F|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

<a href="http://en.wikipedia.org/wiki/Jenkins_hash_function" rel="noreferrer">Wikipedia shows</a> a nice string hash function called Jenkins One At A Time Hash. It also quotes improved versions of this hash.

<pre><code>uint32_t jenkins_one_at_a_time_hash(char *key, size_t len)
{
 uint32_t hash, i;
 for(hash = i = 0; i &lt; len; ++i)
 {
 hash += key[i];
 hash += (hash &lt;&lt; 10);
 hash ^= (hash &gt;&gt; 6);
 }
 hash += (hash &lt;&lt; 3);
 hash ^= (hash &gt;&gt; 11);
 hash += (hash &lt;&lt; 15);
 return hash;
}
</code></pre>

blocks|key|609266|text|有许多现有的用于C的哈希表实现，从C标准库hcreate/hdestroy/hsearch到APR和glib中的实现，它们也提供了预先构建的哈希函数。我强烈建议使用这些，而不是发明自己的哈希表或哈希函数；它们已经针对常见用例进行了大量优化。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|609267|但是，如果数据集是静态的，则最好的解决方案可能是使用perfect+hash。对于给定的数据集，gperf将为您生成完美的哈希。|609268|entityMap|0|LINK|mutability|MUTABLE|url|http://apr.apache.org/|1|http://developer.gnome.org/glib/|2|http://en.wikipedia.org/wiki/Perfect_hash|3|http://www.gnu.org/s/gperf/^0|1A|3|0|1E|4|1|0|Q|C|2|1C|5|3|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]|$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]|$A|14|B|15|1|16]]|C|$]]|$1|F|3|-4|5|6|7|17|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]|P|$5|I|J|K|C|$L|Q]]|R|$5|I|J|K|C|$L|S]]]]

There are a number of existing hashtable implementations for C, from the C standard library hcreate/hdestroy/hsearch, to those in the <a href="http://apr.apache.org/">APR</a> and <a href="http://developer.gnome.org/glib/">glib</a>, which also provide prebuilt hash functions. I'd highly recommend using those rather than inventing your own hashtable or hash function; they've been optimized heavily for common use-cases.

If your dataset is static, however, your best solution is probably to use a <a href="http://en.wikipedia.org/wiki/Perfect_hash">perfect hash</a>. <a href="http://www.gnu.org/s/gperf/">gperf</a> will generate a perfect hash for you for a given dataset.

blocks|key|4368966|text|有一件事我用得很好，那就是(我不知道是否已经提到了，因为我记不住它的名字了)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4368967|您预先计算了一个表T，对于键的字母表0,255中的每个字符都有一个随机数。您可以将密钥'k0+k1+k2+...+kN‘散列为Tk0+xor+Tk1+xor+...异或TkN。你可以很容易地证明这是随机的，就像你的随机数生成器一样，它在计算上非常可行，如果你真的遇到一个非常糟糕的实例，有很多冲突，你可以使用一批新的随机数重复整个过程。|4368968|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One thing I've used with good results is the following (I don't know if its mentioned already because I can't remember its name).

You precompute a table T with a random number for each character in your key's alphabet [0,255]. You hash your key 'k0 k1 k2 ... kN' by taking T[k0] xor T[k1] xor ... xor T[kN]. You can easily show that this is as random as your random number generator and its computationally very feasible and if you really run into a very bad instance with lots of collisions you can just repeat the whole thing using a fresh batch of random numbers.

blocks|key|2753681|text|我尝试了这些散列函数，得到了以下结果。我有大约960%5E3个条目，每个条目64字节长，64个字符按不同顺序排列，散列值为32位。来自here的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2753682|Hash+function++++%7C+collision+rate+%7C+how+many+minutes+to+finish
==============================================================
MurmurHash3++++++%7C+++++++++++6.?%25+%7C++++++++++++++++++++++4m15s
Jenkins+One..++++%7C+++++++++++6.1%25+%7C++++++++++++++++++++++6m54s+++
Bob,+1st+in+link+%7C++++++++++6.16%25+%7C++++++++++++++++++++++5m34s
SuperFastHash++++%7C++++++++++++10%25+%7C++++++++++++++++++++++4m58s
bernstein++++++++%7C++++++++++++20%25+%7C+++++++14s+only+finish+1/20
one_at_a_time++++%7C++++++++++6.16%25+%7C+++++++++++++++++++++++7m5s
crc++++++++++++++%7C++++++++++6.16%25+%7C++++++++++++++++++++++7m56s|code-block|syntax|javascript|2753683|奇怪的是，几乎所有的哈希函数对我的数据都有6%25的冲突率。|2753684|entityMap|0|LINK|mutability|MUTABLE|url|http://burtleburtle.net/bob/hash/doobs.html^0|1T|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]]]

I have tried these hash functions and got the following result. I have about 960^3 entries, each 64 bytes long, 64 chars in different order, hash value 32bit. Codes from <a href="http://burtleburtle.net/bob/hash/doobs.html" rel="nofollow noreferrer">here</a>.

<pre class="lang-none prettyprint-override"><code>Hash function | collision rate | how many minutes to finish
==============================================================
MurmurHash3 | 6.?% | 4m15s
Jenkins One.. | 6.1% | 6m54s 
Bob, 1st in link | 6.16% | 5m34s
SuperFastHash | 10% | 4m58s
bernstein | 20% | 14s only finish 1/20
one_at_a_time | 6.16% | 7m5s
crc | 6.16% | 7m56s
</code></pre>

One strange things is that almost all the hash functions have 6% collision rate for my data.

blocks|key|2753736|text|djb2很好|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2753737|尽管作为presented+on+stackoverflow+by+cnicutar的djb2几乎肯定更好，但我认为它也值得展示K&R散列：|2753738|其中一个K&R散列很糟糕，而另一个可能相当不错：|2753739|2753740|显然是一个糟糕的散列算法，如K&R第一版(source)+unsigned+long+hash(unsigned+char+*str)+{+unsigned+int+hash+=+0；int+c；while+(c+=+*str%2B%2B)+hash+%2B=+c；return+hash；}|ordered-list-item|2753741|2753742|2753743|Probably一个相当不错的散列算法，如K&R版本2中所提出的(我在pg上验证过)。注意:如果您计划在散列算法之外根据数组长度调整模数的大小，请务必从返回语句中删除%25+HASHSIZE。另外，我建议您返回"hashval“类型的整数，而不是简单的unsigned+(+unsigned+long+)。unsigned+hash(char+*s)+{+unsigned+hashval；for+(hashval+=+0；*s+!=+'\0'；s%2B%2B)+hashval+=+*s+%2B+31*+hashval；return+hashval%25HASHSIZE；}|BOLD|2753744|2753745|请注意，从这两个算法可以清楚地看出，第一版散列如此糟糕的一个原因是它没有考虑字符串字符顺序，因此hash("ab")将返回与hash("ba")相同的值。然而，第二版散列不是这样的，它会(好得多！)为这些字符串返回两个不同的值。|2753746|std::unordered_map<>模板容器哈希表使用的GCC+C%2B%2B11哈希函数非常优秀。|2753747|用于++(哈希表模板)和++(哈希集模板)的GCC+C%2B%2B11哈希函数如下所示。|2753748|2753749|This是对GCC使用的散列函数是什么的问题的部分回答，说明GCC使用了“C%2B%2B11”的一个实现，由Austin+Appleby+(http://murmurhash.googlepages.com/).|unordered-list-item|2753750|In文件“gcc/C%2B%2B11%2B%2B-v3/libsupc%2B%2B/MurmurHashUnaligned2_bytes.cc”，在这里(https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/hash_bytes.cc)，我找到了实现。下面是“32位size_t”返回值的示例(拉自2017年8月11日)：|2753751|2753752|代码：|2753753|//+Implementation+of+Murmur+hash+for+32-bit+size_t.
size_t+_Hash_bytes(const+void*+ptr,+size_t+len,+size_t+seed)
{
++const+size_t+m+=+0x5bd1e995;
++size_t+hash+=+seed+%5E+len;
++const+char*+buf+=+static_cast<const+char*>(ptr);

++//+Mix+4+bytes+at+a+time+into+the+hash.
++while+(len+>=+4)
++{
++++size_t+k+=+unaligned_load(buf);
++++k+*=+m;
++++k+%5E=+k+>>+24;
++++k+*=+m;
++++hash+*=+m;
++++hash+%5E=+k;
++++buf+%2B=+4;
++++len+-=+4;
++}

++//+Handle+the+last+few+bytes+of+the+input+array.
++switch+(len)
++{
++++case+3:
++++++hash+%5E=+static_cast<unsigned+char>(buf[2])+<<+16;
++++++[[gnu::fallthrough]];
++++case+2:
++++++hash+%5E=+static_cast<unsigned+char>(buf[1])+<<+8;
++++++[[gnu::fallthrough]];
++++case+1:
++++++hash+%5E=+static_cast<unsigned+char>(buf[0]);
++++++hash+*=+m;
++};

++//+Do+a+few+final+mixes+of+the+hash.
++hash+%5E=+hash+>>+13;
++hash+*=+m;
++hash+%5E=+hash+>>+15;
++return+hash;
}|code-block|syntax|javascript|2753754|Austin+Appleby的MurmerHash3是最好的！这甚至比他上面使用的gcc+C%2B%2B11+std::unordered_map<>散列都是一个改进。|2753755|不仅是所有这些中最好的，而且奥斯汀还将MurmerHash3发布到了公共领域。在这里看我的另一个答案：What+is+the+default+hash+function+used+in+C%2B%2B+std::unordered_map?。|2753756|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/7666577/4561887|1|http://www.cse.yorku.ca/%257Eoz/hash.html|2|https://en.wikipedia.org/wiki/The_C_Programming_Language|3|http://www.cse.yorku.ca/%257Eoz/hash.html|4|https://stackoverflow.com/a/19411888/4561887|5|http://murmurhash.googlepages.com/|6|https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/hash_bytes.cc|7|https://stackoverflow.com/questions/19411742/what-is-the-default-hash-function-used-in-c-stdunordered-map/45641982#45641982^0|0|4|0|17|4|4|12|0|17|4|1|1S|3|2|0|0|0|L|6|3|0|0|0|0|R|2B|A|3G|8|3R|D|0|0|1C|A|1Q|A|0|0|K|0|0|2|4|8|E|Q|0|0|0|4|4|1U|Y|5|0|1T|2A|6|0|0|0|0|1F|K|0|1F|1T|7|0^^$0|@$1|2|3|4|5|6|7|23|8|@$9|24|A|25|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|26|8|@$9|27|A|28|B|C]]|D|@$9|29|A|2A|1|2B]|$9|2C|A|2D|1|2E]|$9|2F|A|2G|1|2H]]|E|$]]|$1|H|3|I|5|6|7|2I|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|2J|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|2K|8|@]|D|@$9|2L|A|2M|1|2N]]|E|$]]|$1|N|3|-4|5|6|7|2O|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|2P|8|@]|D|@]|E|$]]|$1|P|3|Q|5|M|7|2Q|8|@$9|2R|A|2S|B|R]|$9|2T|A|2U|B|C]|$9|2V|A|2W|B|C]|$9|2X|A|2Y|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|2Z|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|30|8|@$9|31|A|32|B|C]|$9|33|A|34|B|C]]|D|@]|E|$]]|$1|V|3|W|5|6|7|35|8|@$9|36|A|37|B|C]]|D|@]|E|$]]|$1|X|3|Y|5|6|7|38|8|@$9|39|A|3A|B|R]|$9|3B|A|3C|B|R]|$9|3D|A|3E|B|R]]|D|@]|E|$]]|$1|Z|3|-4|5|6|7|3F|8|@]|D|@]|E|$]]|$1|10|3|11|5|12|7|3G|8|@]|D|@$9|3H|A|3I|1|3J]|$9|3K|A|3L|1|3M]]|E|$]]|$1|13|3|14|5|12|7|3N|8|@]|D|@$9|3O|A|3P|1|3Q]]|E|$]]|$1|15|3|-4|5|6|7|3R|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|3S|8|@]|D|@]|E|$]]|$1|18|3|19|5|1A|7|3T|8|@]|D|@]|E|$1B|1C]]|$1|1D|3|1E|5|6|7|3U|8|@$9|3V|A|3W|B|C]]|D|@]|E|$]]|$1|1F|3|1G|5|6|7|3X|8|@]|D|@$9|3Y|A|3Z|1|40]]|E|$]]|$1|1H|3|-4|5|6|7|41|8|@]|D|@]|E|$]]]|1I|$1J|$5|1K|1L|1M|E|$1N|1O]]|1P|$5|1K|1L|1M|E|$1N|1Q]]|1R|$5|1K|1L|1M|E|$1N|1S]]|1T|$5|1K|1L|1M|E|$1N|1U]]|1V|$5|1K|1L|1M|E|$1N|1W]]|1X|$5|1K|1L|1M|E|$1N|1Y]]|1Z|$5|1K|1L|1M|E|$1N|20]]|21|$5|1K|1L|1M|E|$1N|22]]]]

<h2><code>djb2</code> is good</h2>
Though <a href="http://www.cse.yorku.ca/%7Eoz/hash.html" rel="nofollow noreferrer"><code>djb2</code></a>, as <a href="https://stackoverflow.com/a/7666577/4561887">presented on stackoverflow by cnicutar</a>, is almost certainly better, I think it's worth showing the <a href="https://en.wikipedia.org/wiki/The_C_Programming_Language" rel="nofollow noreferrer">K&amp;R</a> hashes too:
<h2>One of the K&amp;R hashes is terrible, one is probably pretty good:</h2>
<ol>
<li>Apparently a terrible hash algorithm, as presented in K&amp;R 1st edition (<a href="http://www.cse.yorku.ca/%7Eoz/hash.html" rel="nofollow noreferrer">source</a>)
<pre><code>unsigned long hash(unsigned char *str)
{
 unsigned int hash = 0;
 int c;

 while (c = *str++)
 hash += c;

 return hash;
}
</code></pre>
</li>
<li>Probably a pretty decent hash algorithm, as presented in K&amp;R version 2 (verified by me on pg. 144 of the book); NB: be sure to remove <code>% HASHSIZE</code> from the return statement if you plan on doing the modulus sizing-to-your-array-length outside the hash algorithm. Also, I recommend you make the return and &quot;hashval&quot; type <code>unsigned long</code> instead of the simple <code>unsigned</code> (int).
<pre><code>unsigned hash(char *s)
{
 unsigned hashval;

 for (hashval = 0; *s != '\0'; s++)
 hashval = *s + 31*hashval;
 return hashval % HASHSIZE;
}
</code></pre>
</li>
</ol>
Note that it's clear from the two algorithms that one reason the 1st edition hash is so terrible is because it does NOT take into consideration string character order, so <code>hash(&quot;ab&quot;)</code> would therefore return the same value as <code>hash(&quot;ba&quot;)</code>. This is not so with the 2nd edition hash, however, which would (much better!) return two different values for those strings.
<h2>The GCC C++11 hashing function used by the <code>std::unordered_map&lt;&gt;</code> template container hash table is excellent.</h2>
The GCC C++11 hashing functions used for <a href="http://www.cplusplus.com/reference/unordered_map/unordered_map/" rel="nofollow noreferrer"><code>unordered_map</code></a> (a hash table template) and <a href="http://www.cplusplus.com/reference/unordered_set/unordered_set/" rel="nofollow noreferrer"><code>unordered_set</code></a> (a hash set template) appear to be as follows.
<ul>
<li><a href="https://stackoverflow.com/a/19411888/4561887">This</a> is a partial answer to the question of what are the GCC C++11 hash functions used, stating that GCC uses an implementation of &quot;MurmurHashUnaligned2&quot;, by Austin Appleby (<a href="http://murmurhash.googlepages.com/" rel="nofollow noreferrer">http://murmurhash.googlepages.com/</a>).</li>
<li>In the file &quot;gcc/libstdc++-v3/libsupc++/hash_bytes.cc&quot;, here (<a href="https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/libsupc++/hash_bytes.cc" rel="nofollow noreferrer">https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/libsupc++/hash_bytes.cc</a>), I found the implementations. Here's the one for the &quot;32-bit size_t&quot; return value, for example (pulled 11 Aug 2017):</li>
</ul>
Code:
<pre><code>// Implementation of Murmur hash for 32-bit size_t.
size_t _Hash_bytes(const void* ptr, size_t len, size_t seed)
{
 const size_t m = 0x5bd1e995;
 size_t hash = seed ^ len;
 const char* buf = static_cast&lt;const char*&gt;(ptr);

 // Mix 4 bytes at a time into the hash.
 while (len &gt;= 4)
 {
 size_t k = unaligned_load(buf);
 k *= m;
 k ^= k &gt;&gt; 24;
 k *= m;
 hash *= m;
 hash ^= k;
 buf += 4;
 len -= 4;
 }

 // Handle the last few bytes of the input array.
 switch (len)
 {
 case 3:
 hash ^= static_cast&lt;unsigned char&gt;(buf[2]) &lt;&lt; 16;
 [[gnu::fallthrough]];
 case 2:
 hash ^= static_cast&lt;unsigned char&gt;(buf[1]) &lt;&lt; 8;
 [[gnu::fallthrough]];
 case 1:
 hash ^= static_cast&lt;unsigned char&gt;(buf[0]);
 hash *= m;
 };

 // Do a few final mixes of the hash.
 hash ^= hash &gt;&gt; 13;
 hash *= m;
 hash ^= hash &gt;&gt; 15;
 return hash;
}
</code></pre>
<h2>MurmerHash3 by Austin Appleby is best! It's an improvement over even his gcc C++11 <code>std::unordered_map&lt;&gt;</code> hash used above.</h2>
Not only is is the best of all of these, but Austin released MurmerHash3 into the public domain. See my other answer on this here: <a href="https://stackoverflow.com/questions/19411742/what-is-the-default-hash-function-used-in-c-stdunordered-map/45641982#45641982">What is the default hash function used in C++ std::unordered_map?</a>.

blocks|key|2753796|text|djb2对于this+466k+english+dictionary有317个冲突，而MurmurHash对于64位散列没有冲突，对于32位散列有21个冲突(对于466k随机32位散列，预计大约有25个)。我的建议是使用MurmurHash，如果可用的话，它是非常快的，因为它一次接受几个字节。但是如果你需要一个简单而简短的散列函数来复制并粘贴到你的项目中，我建议使用your+a-byte-a-time版本：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2753797|uint32_t+inline+MurmurOAAT32+(+const+char+*+key)
{
++uint32_t+h(3323198485ul);
++for+(;*key;%2B%2Bkey)+{
++++h+%5E=+*key;
++++h+*=+0x5bd1e995;
++++h+%5E=+h+>>+15;
++}
++return+h;
}

uint64_t+inline+MurmurOAAT64+(+const+char+*+key)
{
++uint64_t+h(525201411107845655ull);
++for+(;*key;%2B%2Bkey)+{
++++h+%5E=+*key;
++++h+*=+0x5bd1e9955bd1e995;
++++h+%5E=+h+>>+47;
++}
++return+h;
}|code-block|syntax|javascript|2753798|简而言之，哈希表的最佳大小是尽可能大，同时仍能放入内存中。因为我们通常不知道或不想查看有多少可用内存，甚至可能会发生变化，所以最优的哈希表大小大约是表中要存储的元素预期数量的2倍。分配更多的哈希表将使您的哈希表更快，但在快速递减的回报，使您的哈希表小于这将使它指数级的慢。这是因为存在用于哈希表的非线性trade-off+between+space+and+time+complexity，其最佳负载因子为2-sqrt(2)+=+0.58...很明显。|2753799|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/dwyl/english-words/blob/master/words.txt|1|https://en.wikipedia.org/wiki/MurmurHash|2|https://1ykos.github.io/patchmap/#Performance%2520comparison^0|6|S|0|32|A|1|0|0|47|17|2|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]|$A|10|B|11|1|12]]|C|$]]|$1|D|3|E|5|F|7|13|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|K|3|-4|5|6|7|18|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]|S|$5|N|O|P|C|$Q|T]]|U|$5|N|O|P|C|$Q|V]]]]

djb2 has 317 collisions for <a href="https://github.com/dwyl/english-words/blob/master/words.txt" rel="noreferrer">this 466k english dictionary</a> while MurmurHash has none for 64 bit hashes, and 21 for 32 bit hashes (around 25 is to be expected for 466k random 32 bit hashes).
My recommendation is using <a href="https://en.wikipedia.org/wiki/MurmurHash" rel="noreferrer">MurmurHash</a> if available, it is very fast, because it takes in several bytes at a time. But if you need a simple and short hash function to copy and paste to your project I'd recommend using murmurs one-byte-at-a-time version:

<pre><code>uint32_t inline MurmurOAAT32 ( const char * key)
{
 uint32_t h(3323198485ul);
 for (;*key;++key) {
 h ^= *key;
 h *= 0x5bd1e995;
 h ^= h &gt;&gt; 15;
 }
 return h;
}

uint64_t inline MurmurOAAT64 ( const char * key)
{
 uint64_t h(525201411107845655ull);
 for (;*key;++key) {
 h ^= *key;
 h *= 0x5bd1e9955bd1e995;
 h ^= h &gt;&gt; 47;
 }
 return h;
}
</code></pre>

The optimal size of a hash table is - in short - as large as possible while still fitting into memory. Because we don't usually know or want to look up how much memory we have available, and it might even change, the optimal hash table size is roughly 2x the expected number of elements to be stored in the table. Allocating much more than that will make your hash table faster but at rapidly diminishing returns, making your hash table smaller than that will make it exponentially slower. This is because there is a non-linear <a href="https://1ykos.github.io/patchmap/#Performance%20comparison" rel="noreferrer">trade-off between space and time complexity</a> for hash tables, with an optimal load factor of 2-sqrt(2) = 0.58... apparently.

blocks|key|609386|text|我想验证边晓宁的答案，但不幸的是他没有发布他的代码。因此，我实现了一个小测试套件，并在466K+English+words列表上运行了不同的小散列函数，以查看每个函数的冲突数量：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|609387|Hash+function++++++%7C+++++Collisions+%7C+Time+(words)+%7C+Time+(file)
=================================================================
CRC32++++++++++++++%7C++++23+(0.005%25)+%7C++++++112+ms++%7C++++++38+ms
MurmurOAAT+++++++++%7C++++26+(0.006%25)+%7C+++++++86+ms++%7C++++++10+ms
FNV+hash+++++++++++%7C++++32+(0.007%25)+%7C+++++++87+ms++%7C+++++++7+ms
Jenkins+OAAT+++++++%7C++++36+(0.008%25)+%7C+++++++90+ms++%7C+++++++8+ms
DJB2+hash++++++++++%7C+++344+(0.074%25)+%7C+++++++87+ms++%7C+++++++5+ms
K&R+V2+++++++++++++%7C+++356+(0.076%25)+%7C+++++++86+ms++%7C+++++++5+ms
Coffin+++++++++++++%7C+++763+(0.164%25)+%7C+++++++86+ms++%7C+++++++4+ms
x17+hash+++++++++++%7C++2242+(0.481%25)+%7C+++++++87+ms++%7C+++++++7+ms
-----------------------------------------------------------------
MurmurHash3_x86_32+%7C++++19+(0.004%25)+%7C+++++++90+ms++%7C+++++++3+ms|code-block|syntax|javascript|609388|我包括了这两个方面的时间:分别对所有单词进行散列，并对所有英语单词的整个文件进行一次散列。我还在我的测试中包含了一个更复杂的MurmurHash3_x86_32以供参考。|style|CODE|609389|结论：|609390|609391|在英特尔x86-64体系结构上，对字符串使用流行的DJB2散列函数几乎没有意义。因为它比类似的函数(MurmurOAAT、FNV和Jenkins+OAAT)有更多的冲突，同时具有非常相似的吞吐量。伯恩斯坦的DJB2在短字符串上的表现尤其糟糕。冲突示例：Liz/MHz、Bon/COM、MHz|unordered-list-item|609392|609393|测试代码：|609394|#include+<stdio.h>
#include+<stdint.h>
#include+<stdlib.h>
#include+<string.h>

#define+MAXLINE+2048
#define+SEED++++0x12345678

uint32_t+DJB2_hash(const+uint8_t+*str)
{
++++uint32_t+hash+=+5381;
++++uint8_t+c;
++++while+((c+=+*str%2B%2B))
++++++++hash+=+((hash+<<+5)+%2B+hash)+%2B+c;+/*+hash+*+33+%2B+c+*/
++++return+hash;
}

uint32_t+FNV(const+void*+key,+int+len,+uint32_t+h)
{
++++//+Source:+https://github.com/aappleby/smhasher/blob/master/src/Hashes.cpp
++++h+%5E=+2166136261UL;
++++const+uint8_t*+data+=+(const+uint8_t*)key;
++++for(int+i+=+0;+i+<+len;+i%2B%2B)
++++{
++++++++h+%5E=+data[i];
++++++++h+*=+16777619;
++++}
++++return+h;
}

uint32_t+MurmurOAAT_32(const+char*+str,+uint32_t+h)
{
++++//+One-byte-at-a-time+hash+based+on+Murmur's+mix
++++//+Source:+https://github.com/aappleby/smhasher/blob/master/src/Hashes.cpp
++++for+(;+*str;+%2B%2Bstr)+{
++++++++h+%5E=+*str;
++++++++h+*=+0x5bd1e995;
++++++++h+%5E=+h+>>+15;
++++}
++++return+h;
}

uint32_t+KR_v2_hash(const+char+*s)
{
++++//+Source:+https://stackoverflow.com/a/45641002/5407270
++++uint32_t+hashval+=+0;
++++for+(hashval+=+0;+*s+!=+'\0';+s%2B%2B)
++++++++hashval+=+*s+%2B+31*hashval;
++++return+hashval;
}

uint32_t+Jenkins_one_at_a_time_hash(const+char+*str,+size_t+len)
{
++++uint32_t+hash,+i;
++++for(hash+=+i+=+0;+i+<+len;+%2B%2Bi)
++++{
++++++++hash+%2B=+str[i];
++++++++hash+%2B=+(hash+<<+10);
++++++++hash+%5E=+(hash+>>+6);
++++}
++++hash+%2B=+(hash+<<+3);
++++hash+%5E=+(hash+>>+11);
++++hash+%2B=+(hash+<<+15);
++++return+hash;
}

uint32_t+crc32b(const+uint8_t+*str)+{
++++//+Source:+https://stackoverflow.com/a/21001712
++++unsigned+int+byte,+crc,+mask;
++++int+i+=+0,+j;
++++crc+=+0xFFFFFFFF;
++++while+(str[i]+!=+0)+{
++++++++byte+=+str[i];
++++++++crc+=+crc+%5E+byte;
++++++++for+(j+=+7;+j+>=+0;+j--)+{
++++++++++++mask+=+-(crc+&+1);
++++++++++++crc+=+(crc+>>+1)+%5E+(0xEDB88320+&+mask);
++++++++}
++++++++i+=+i+%2B+1;
++++}
++++return+~crc;
}

inline+uint32_t+_rotl32(uint32_t+x,+int32_t+bits)
{
++++return+x<<bits+%7C+x>>(32-bits);++++++//+C+idiom:+will+be+optimized+to+a+single+operation
}

uint32_t+Coffin_hash(char+const+*input)+{+
++++//+Source:+https://stackoverflow.com/a/7666668/5407270
++++uint32_t+result+=+0x55555555;
++++while+(*input)+{+
++++++++result+%5E=+*input%2B%2B;
++++++++result+=+_rotl32(result,+5);
++++}
++++return+result;
}

uint32_t+x17(const+void+*+key,+int+len,+uint32_t+h)
{
++++//+Source:+https://github.com/aappleby/smhasher/blob/master/src/Hashes.cpp
++++const+uint8_t+*+data+=+(const+uint8_t*)key;
++++for+(int+i+=+0;+i+<+len;+%2B%2Bi)
++++{
++++++++h+=+17+*+h+%2B+(data[i]+-+'+');
++++}
++++return+h+%5E+(h+>>+16);
}

uint32_t+apply_hash(int+hash,+const+char*+line)
{
++++switch+(hash)+{
++++case+1:+return+crc32b((const+uint8_t*)line);
++++case+2:+return+MurmurOAAT_32(line,+SEED);
++++case+3:+return+FNV(line,+strlen(line),+SEED);
++++case+4:+return+Jenkins_one_at_a_time_hash(line,+strlen(line));
++++case+5:+return+DJB2_hash((const+uint8_t*)line);
++++case+6:+return+KR_v2_hash(line);
++++case+7:+return+Coffin_hash(line);
++++case+8:+return+x17(line,+strlen(line),+SEED);
++++default:+break;
++++}
++++return+0;
}

int+main(int+argc,+char*+argv[])
{
++++//+Read+arguments
++++const+int+hash_choice+=+atoi(argv[1]);
++++char+const*+const+fn+=+argv[2];

++++//+Read+file
++++FILE*+f+=+fopen(fn,+"r");

++++//+Read+file+line+by+line,+calculate+hash
++++char+line[MAXLINE];
++++while+(fgets(line,+sizeof(line),+f))+{
++++++++line[strcspn(line,+"\n")]+=+'\0';+++//+strip+newline
++++++++uint32_t+hash+=+apply_hash(hash_choice,+line);
++++++++printf("%2508x\n",+hash);
++++}
++++fclose(f);

++++return+0;
}|609395|关于现代散列函数的速度和质量的更全面的评论，可以在Reini+can+(郊区)的SMHasher+repository中找到。请注意表格中的"Quality+problems“列。|609396|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/dwyl/english-words/blob/master/words.txt|1|https://en.wikipedia.org/wiki/Fowler%25E2%2580%2593Noll%25E2%2580%2593Vo_hash_function|2|https://en.wikipedia.org/wiki/Jenkins_hash_function#one_at_a_time|3|https://github.com/rurban/smhasher^0|17|I|0|0|0|1Q|I|0|0|0|3I|3|3M|3|3Q|3|3U|3|3Y|3|1P|3|1|1T|C|2|0|0|0|0|14|J|3|0^^$0|@$1|2|3|4|5|6|7|1D|8|@]|9|@$A|1E|B|1F|1|1G]]|C|$]]|$1|D|3|E|5|F|7|1H|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|1I|8|@$A|1J|B|1K|K|L]]|9|@]|C|$]]|$1|M|3|N|5|6|7|1L|8|@]|9|@]|C|$]]|$1|O|3|-4|5|6|7|1M|8|@]|9|@]|C|$]]|$1|P|3|Q|5|R|7|1N|8|@$A|1O|B|1P|K|L]|$A|1Q|B|1R|K|L]|$A|1S|B|1T|K|L]|$A|1U|B|1V|K|L]|$A|1W|B|1X|K|L]]|9|@$A|1Y|B|1Z|1|20]|$A|21|B|22|1|23]]|C|$]]|$1|S|3|-4|5|6|7|24|8|@]|9|@]|C|$]]|$1|T|3|U|5|6|7|25|8|@]|9|@]|C|$]]|$1|V|3|W|5|F|7|26|8|@]|9|@]|C|$G|H]]|$1|X|3|Y|5|6|7|27|8|@]|9|@$A|28|B|29|1|2A]]|C|$]]|$1|Z|3|-4|5|6|7|2B|8|@]|9|@]|C|$]]]|10|$11|$5|12|13|14|C|$15|16]]|17|$5|12|13|14|C|$15|18]]|19|$5|12|13|14|C|$15|1A]]|1B|$5|12|13|14|C|$15|1C]]]]

I wanted to verify Xiaoning Bian's answer, but unfortunately he didn't post his code. So I implemented a little test suite and ran different little hashing functions on the list of <a href="https://github.com/dwyl/english-words/blob/master/words.txt" rel="nofollow noreferrer">466K English words</a> to see number of collisions for each:
<pre><code>Hash function | Collisions | Time (words) | Time (file)
=================================================================
CRC32 | 23 (0.005%) | 112 ms | 38 ms
MurmurOAAT | 26 (0.006%) | 86 ms | 10 ms
FNV hash | 32 (0.007%) | 87 ms | 7 ms
Jenkins OAAT | 36 (0.008%) | 90 ms | 8 ms
DJB2 hash | 344 (0.074%) | 87 ms | 5 ms
K&amp;R V2 | 356 (0.076%) | 86 ms | 5 ms
Coffin | 763 (0.164%) | 86 ms | 4 ms
x17 hash | 2242 (0.481%) | 87 ms | 7 ms
-----------------------------------------------------------------
MurmurHash3_x86_32 | 19 (0.004%) | 90 ms | 3 ms
</code></pre>
I included time for both: hashing all words individually and hashing the entire file of all English words once. I also included a more complex <code>MurmurHash3_x86_32</code> into my test for reference.
Conclusion:
<ul>
<li>there is almost no point of using the popular DJB2 hash function for strings on Intel x86-64 architecture. Because it has much more collisions than similar functions (MurmurOAAT, <a href="https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function" rel="nofollow noreferrer">FNV</a> and <a href="https://en.wikipedia.org/wiki/Jenkins_hash_function#one_at_a_time" rel="nofollow noreferrer">Jenkins OAAT</a>) while having very similar throughput. Bernstein's DJB2 performs especially bad on short strings. Example collisions: <code>Liz</code>/<code>MHz</code>, <code>Bon</code>/<code>COM</code>, <code>Rey</code>/<code>SEX</code>.</li>
</ul>
Test code:
<pre><code>#include &lt;stdio.h&gt;
#include &lt;stdint.h&gt;
#include &lt;stdlib.h&gt;
#include &lt;string.h&gt;

#define MAXLINE 2048
#define SEED 0x12345678

uint32_t DJB2_hash(const uint8_t *str)
{
 uint32_t hash = 5381;
 uint8_t c;
 while ((c = *str++))
 hash = ((hash &lt;&lt; 5) + hash) + c; /* hash * 33 + c */
 return hash;
}

uint32_t FNV(const void* key, int len, uint32_t h)
{
 // Source: https://github.com/aappleby/smhasher/blob/master/src/Hashes.cpp
 h ^= 2166136261UL;
 const uint8_t* data = (const uint8_t*)key;
 for(int i = 0; i &lt; len; i++)
 {
 h ^= data[i];
 h *= 16777619;
 }
 return h;
}

uint32_t MurmurOAAT_32(const char* str, uint32_t h)
{
 // One-byte-at-a-time hash based on Murmur's mix
 // Source: https://github.com/aappleby/smhasher/blob/master/src/Hashes.cpp
 for (; *str; ++str) {
 h ^= *str;
 h *= 0x5bd1e995;
 h ^= h &gt;&gt; 15;
 }
 return h;
}

uint32_t KR_v2_hash(const char *s)
{
 // Source: https://stackoverflow.com/a/45641002/5407270
 uint32_t hashval = 0;
 for (hashval = 0; *s != '\0'; s++)
 hashval = *s + 31*hashval;
 return hashval;
}

uint32_t Jenkins_one_at_a_time_hash(const char *str, size_t len)
{
 uint32_t hash, i;
 for(hash = i = 0; i &lt; len; ++i)
 {
 hash += str[i];
 hash += (hash &lt;&lt; 10);
 hash ^= (hash &gt;&gt; 6);
 }
 hash += (hash &lt;&lt; 3);
 hash ^= (hash &gt;&gt; 11);
 hash += (hash &lt;&lt; 15);
 return hash;
}

uint32_t crc32b(const uint8_t *str) {
 // Source: https://stackoverflow.com/a/21001712
 unsigned int byte, crc, mask;
 int i = 0, j;
 crc = 0xFFFFFFFF;
 while (str[i] != 0) {
 byte = str[i];
 crc = crc ^ byte;
 for (j = 7; j &gt;= 0; j--) {
 mask = -(crc &amp; 1);
 crc = (crc &gt;&gt; 1) ^ (0xEDB88320 &amp; mask);
 }
 i = i + 1;
 }
 return ~crc;
}

inline uint32_t _rotl32(uint32_t x, int32_t bits)
{
 return x&lt;&lt;bits | x&gt;&gt;(32-bits); // C idiom: will be optimized to a single operation
}

uint32_t Coffin_hash(char const *input) { 
 // Source: https://stackoverflow.com/a/7666668/5407270
 uint32_t result = 0x55555555;
 while (*input) { 
 result ^= *input++;
 result = _rotl32(result, 5);
 }
 return result;
}

uint32_t x17(const void * key, int len, uint32_t h)
{
 // Source: https://github.com/aappleby/smhasher/blob/master/src/Hashes.cpp
 const uint8_t * data = (const uint8_t*)key;
 for (int i = 0; i &lt; len; ++i)
 {
 h = 17 * h + (data[i] - ' ');
 }
 return h ^ (h &gt;&gt; 16);
}

uint32_t apply_hash(int hash, const char* line)
{
 switch (hash) {
 case 1: return crc32b((const uint8_t*)line);
 case 2: return MurmurOAAT_32(line, SEED);
 case 3: return FNV(line, strlen(line), SEED);
 case 4: return Jenkins_one_at_a_time_hash(line, strlen(line));
 case 5: return DJB2_hash((const uint8_t*)line);
 case 6: return KR_v2_hash(line);
 case 7: return Coffin_hash(line);
 case 8: return x17(line, strlen(line), SEED);
 default: break;
 }
 return 0;
}

int main(int argc, char* argv[])
{
 // Read arguments
 const int hash_choice = atoi(argv[1]);
 char const* const fn = argv[2];

 // Read file
 FILE* f = fopen(fn, &quot;r&quot;);

 // Read file line by line, calculate hash
 char line[MAXLINE];
 while (fgets(line, sizeof(line), f)) {
 line[strcspn(line, &quot;\n&quot;)] = '\0'; // strip newline
 uint32_t hash = apply_hash(hash_choice, line);
 printf(&quot;%08x\n&quot;, hash);
 }
 fclose(f);

 return 0;
}
</code></pre>
P.S. A more comprehensive review of speed and quality of modern hash functions can be found in <a href="https://github.com/rurban/smhasher" rel="nofollow noreferrer">SMHasher repository</a> of Reini Urban (rurban). Notice the &quot;Quality problems&quot; column in the table.

I'm working on hash table in C language and I'm testing hash function for string.

The first function I've tried is to add ascii code and use modulo (%100) but i've got poor results with the first test of data: 40 collisions for 130 words. 

The final input data will contain 8 000 words (it's a dictionnary stores in a file). The hash table is declared as int table[10000] and contains the position of the word in a txt file.

The first question is which is the best algorithm for hashing string ? and how to determinate the size of hash table ?

thanks in advance !

:-)

hash function for string

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我正在用C语言编写哈希表，我正在测试字符串的哈希函数。我尝试的第一个函数是添加ascii代码并使用模数(%100)，但我在第一次数据测试中得到了很差的结果: 130个单词发生40次冲突。最终的输入数据将包含8000个单词(它是一个存储在文件中的字典)。哈希表被声明为int table10000，并且包含单词在txt文件...

问字符串的散列函数
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问字符串的散列函数EN