Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk