Re: [boost] [review] hash functions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-09 15:08:18

Dave Harris wrote:
> In-Reply-To: <d0kr8r$gl6$1_at_[hidden]>
> nesotto_at_[hidden] (Thorsten Ottosen) wrote (abridged):
>> It's a pleasure to announce that the review of Daniel James' hash
>> functions library starts today (8th of March) and ends the 12th
>> of March.
>
> I have some questions about the design.
>
> First, why does hash_combine have a void result, and have
> side-effects on its arguments? Wouldn't a pure, side-effect free function 
> be
> better?

This is done to emphasize the fact that the hash value of the second 
argument is accumulated into the first (the seed). A pure function would 
entice you to define hash_value for (x, y) as hash_combine(x, y). The 
current design forces you to think in terms of an initial seed that is 
modified by each value.

> Second, why doesn't hash_range depend on the length of the sequence?
> For example, the hash_range of { 12 } and { 0, 0, 0, 12 } are the
> same. I'd rather they gave different results.
>
> Thirdly, the hash values love producing 0. For example, hash_value(
> (char *) NULL ) and hash_value( false ) are both 0. hash_combine on a
> range of 0s will produce another 0. Am I the only person who sees
> this as a problem?

We can fix this by initializing the seed in hash_range with something other 
than zero. It isn't a problem for strings, where \0 is rare, but may be a 
problem for arbitrary sequences.