hash_value(float) collision

[dsharlet@…]

the hash_value function for floats has at least one collision that is rather serious:

std::size_t zero = boost::hash_value(0.0f); std::size_t half = boost::hash_value(0.5f);

both of these have the same hash value. Why not just use reinterpret_cast <> for this hash function?

[Daniel James]

Because in cross platform development there's no guarantee that two floats with different binary representations will be unequal, and there's no guarantee that the binary representation will be the same size as std::size_t. I do use a binary algorithm on a limited number of platforms, and could for others, but it has to be done carefully and there are more important things to do.

[Daniel James]

(In [60805]) Remove optimization which causes 0.5 to hash to 0. Refs #4038.

I have an internal requirement the 0 hashes to 0, a better solution might be to remove that, put the optimization back and hash 0 to another value. Or alternatively, use the main combine function instead.

[Daniel James]

(In [60980]) Merge from trunk.

• Add quick_erase for unordered. erase_return_void is now deprecated. Fixes #3966
• Avoid collision between 0 and 0.5. Fixes #4038