Alexander Nasonov wrote:
It doesn't have to be documented but boost::hash has some side effects which worth mentioning in "Standard Conformity" section. For example, boost::hash is valid for enums even if hash_value is not specialized
To be honest, this never occured to me. Although, I guess it is implied by careful reading of the reference documentation (ie. more careful than my writing). It actually deals with enums very nicely and I wouldn't be suprised if Peter (who wrote the original design) had anticipated this. I'll think about this and add something to the documentation (for 1.34).
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. 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. I think the only potential problem is if a user defined type has a hash_value function which means something different. A programmer using this type with Boost.MultiIndex or the proposed unordered containers could be completely ignorant of boost::hash as it's used by default. Although, this seems pretty unlikely to me as 'hash_value' is a fairly unambiguous name. And of course, the same problems could happen for std::equal_to, if operator== is overloaded. There's been a long debate about this sort of issue concerning Boost.Range (I'm afraid I lost track of it a while ago. I really should try to catch up, but time is always a problem). In case you're interested, I did at one point consider having a different version for Boost.TR1: http://lists.boost.org/Archives/boost/2005/02/79892.php http://lists.boost.org/Archives/boost/2005/02/79950.php It wouldn't be too hard to provide a 'strict mode' activated by a macro, but I don't really think it would be that useful.
3. A link to books.hpp leads to books.cpp (note h and c) http://www.boost.org/doc/html/hash/custom.html. Currently, I can't access cvs and fix it myself.
OK, I'll fix that soon (for 1.33.1). Daniel