Boost logo

Boost :

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