From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-04-10 08:39:19
Daniel James wrote:
> I've just checked in an attempt at supporting built-in arrays in
> boost::hash. It's not great and I might remove it before Friday. My
> main problem was that overloading hash_value for both T* and T[Size]
> causes ambiguity - so I implemented it using partial specialization of
> call_hash. (If anyone knows how to correctly implement the overload,
> preferably without SFINAE, let me know, although I'll spend some time
> looking into it if I can find the time).
Indeed it does! I learn something new every day. ;-)
> So I implemented it using partial specialization of
> hash_detail::call_hash. This breaks the specification of
> boost::hash_combine, which is specified in terms of boost::hash_value
> - but boost::hash_value is not overloaded for built in arrays.
> So it might be a good idea to change it so that it's specified in terms of
> boost::hash. In a way, I prefer this, since users should never really call
> hash_value directly and I think the documentation should reinforce this.
> Any thoughts Peter?
I'd prefer it if hash_value "just works" and does the right thing. If we
can't do this, we should probably just drop support for built-in arrays.
How about changing the pointer overload to
size_t hash_value( void const volatile * p );
This doesn't handle pointers to functions, so we'd need a separate overload
SFINAEd on is_function; but since hashing function pointers is relatively
rare, it won't be a problem if it doesn't work on all compilers.
Or perhaps just switching to:
template<class T> size_t hash_value( T * const & p );
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk