[boost] Re: [review] hash functions

From: Daniel James (daniel_at_[hidden])
Date: 2005-03-14 07:33:43

Topher Cooper wrote:

> I am made very uncomfortable, however when we put structs (and 
> therefore, by a primary identity in the C++ language, classes) into the 
> mix.  Here we may have inheritance relationship (not a union) where two 
> different types with different meanings to the quantities can end up 
> introducing a tendency for rather different things to hash to the same 
> values.  I presented the example of two different classes representing 
> polar and Cartesian representation of complex numbers (and, yes, I have 
> written packages where these two representations co-exist and intermix 
> to allow optimizations).  Of course for this example, you would clearly 
> want a custom hash, but the point is, subclassing does not make this 
> situation that bizarre.  What about a table containing structs for 
> Resources, which could represent either employees or pieces of office 
> equipment where the characteristics of interest in each happen to all be 
> represented as a bunch of booleans, that happen to be the same length?

Think about how such a class would be stored in the proposed unordered 
associative containers. If you use unordered_set<base*> then the hash 
function will be called for the pointer, not the class. If you use 
unordered_set<boost::shared_ptr<base> >, then it depends on how Peter 
implements the hash function for shared_ptr, but I expect it will be the 
pointer again. If you use unordered_set<boost::variant<...> > or 
unordered_set<boost::any<...> > then a correctly written hash function 
for boost::variant or boost::any will be fine.

If Thorsten writes ptr_unordered_set<base> then there might be a problem 
with boost::hash<base>. Although it will equally apply to 
std::equal_to<base>.

boost::hash<X> and boost::hash<Y> (where X != Y) aren't designed to be 
used together.