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 ); ?