Daniel James wrote:
Alexander Nasonov wrote:
2. Adding new has_value may have side effects, for example, (a) hash<T> may compile for not customized type T although T doesn't necesarily have properly defined equality function; or (b) it may introduce overload resolution ambiguities, in worst case, hash<type_from_6_3_3_1> may stop working.
I don't think this is nearly as bad as you think. Any type from TR1 will only stop working if you declare hash_value in the boost or std namespace - which you really shouldn't do.
You are right. I was a way too pessimistic.
If a type has a hash_value function but no equality then boost::hash will compile for it - but a hashed container won't, because it will require the equality function. So the only time will boost::hash will work is if it's used in another context where equality isn't required.
That's not quite right. For example #include <iostream> #include <boost/functional/hash.hpp> struct Base { bool operator==(Base) const { return true; } }; std::size_t hash_value(Base) { return 0; // Base has no state } struct Derived : Base { int dummy; bool operator==(Derived other) const { return dummy == other.dummy; } }; int main() { Derived x; std::cout << boost::hash<Derived>()(x) << '\n'; } -- Alexander Nasonov