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.