为什么在最坏的情况下，unorded_set重新哈希复杂度可能为O（n ^ 2）？

Question

I don't understand why it is not linear.

There is a good answer for similar question about multiset: why hastable's rehash complexity may be quadratic in worst case

But what about set? It could be only one element for each key.

Update:

Many keys in one bucket is also not a problem. We can go through them in a linear time.

I think the right answer as mentioned below is that O(n^2) rehash complexity included in the standard to allow open adressing(and may be some other) implementation.

Answer 1

Basically, it would be possible to build a hash set that has O(n) worst case rehash time. It would even be possible to build a multiset with this property that still grants the same guarantee that elements with the same key are behind each other in a bucket, so the link you state is wrong . (Well, not fully wrong, it admits that there may be O(n) implementations)

It works like this:

for each bucket b of old table
    for each element e in bucket b
        b' = new bucket of e
        prepend e before the first entry in b' // <---- this is the key optimization

The algorithm works for sets and multisets and is extremely simple. Instead of appending elements to the new bucket (which would be O(number of elements in the bucket) ) we prepend to the bucket which is O(1) (simply change two pointers).

Of course, this will reverse the elements in the bucket. But this is okay since the key multimap assumption that equal elements are behind each other still holds.

But beware of open addressing

My solution only works for hashing with chaining. It does not work for open addressing. Thus, since the spec surely wants to allow both implementation methods, it must state that O(n²) might be the worst case, even if there are implementations that have better asymptotic runtimes.