Re: [boost] [hash] documentation issues (was [TR1 Review] TR1 Formal Review Beginning)

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:

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