From: Daniel James (daniel_at_[hidden])
Date: 2005-09-29 12:25:52
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
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
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:
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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk