Boost logo

Boost :

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
> 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:

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)
> 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, gregod at, cpdaniel at, john at