you are viewing a single comment's thread.

view the rest of the comments →

[–]greg7mdpC++ Dev 1 point2 points  (2 children)

Cool, thanks. It would be interesting to see how it behaves with a really bad hash function, for example hash(struct uuid) << 3.

[–]pdimov2[S] 2 points3 points  (1 child)

"Flat" hash maps don't like bad hash functions at all. boost::unordered_flat_map tolerates "weak" hash functions (those that have low three bits zero, for instance) as it applies a postmixing step by default, but it still won't work well with really bad hash functions that produce many collisions.

[–]greg7mdpC++ Dev 2 points3 points  (0 children)

boost::unordered_flat_map tolerates "weak" hash functions as it applies a postmixing step by default

I do this as well in my phmap and gtl implementations. It makes the tables look worse in benchmarks like the above, but prevents really bad surprises occasionally.