Re: [boost] [review] hash functions

From: John Maddock (john_at_[hidden])
Date: 2005-03-14 12:04:26

> 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.

How so, there is no automatic hashing of classes or structs (since there is 
no reflection in C++), and different classes can't be stored in the same 
hash container anyway.  It's true that a vector<int> and a deque<int> with 
the same contents would hash to the same value, but again vectors and deques 
can't be stored in the same indexed container, and I rather like the 
predictability that this offers: if I change my code from vector<int> to 
deque<int> I would expect hashes to behave in the same way (I don't care 
whether they produce the same values, but I do care that the risk of 
collisions is the same in either case, given that they are holding the same 
data).  We could use a different seed value for each T ( 
hash_value(&typeinfo(T)) ? ), but that seems like overkill.

> 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).

Can you store these in the same container? If so then how could any 
implementation tell them apart anyway?

> 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?

Again, either the tables are the same type, and no implementation can tell 
them apart anyway, or they are different types, and they can't be mixed in 
the same container anyway.

Would this concern be fixed by adding some information to the documentation?

John.