Re: [boost] Re: [review] hash functions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-15 13:07:15

Dave Harris wrote:
> In-Reply-To: <d11prg$uvt$1_at_[hidden]>
> daniel_at_[hidden] (Daniel James) wrote (abridged):
>> Well, we did discus the type of review before it started, and nobody
>> raised any objections.
>
> That's partly because it sounded like the interface was fixed and known
> good. Where-as we are now agreed that hash_range is going to take at
> least one additional parameter and possibly be renamed (to
> hash_combine) and the return type maybe changed to void; so the
> interface is not fixed.

No, we are not. ;-)

I still support the original proposal, with the following additions:

1. Bias hash_value(v) in hash_combine to avoid the zero trap.
2. Add a hash_range overload that takes a seed.

(2) can take the following forms:

2a. void hash_range( size_t & seed, It first, It last );
2b. size_t hash_range( size_t seed, It first, It last );
2c. size_t hash_range( It first, It last, size_t seed );

which are listed in order of my preference. The version with a default 
argument is equivalent to the current proposal with (2c) added.

Rationale: I prefer the seed as a first argument for consistency with 
hash_combine. I prefer (2a) to emphasize the fact that this overload is 
intended to be used when you already have a 'seed' variable that accumulates 
the hash value computed so far.

Rationale for (1):

I think that it is better to fix the zero trap in hash_combine, because this 
does not depend on users remembering to initialize the seed to default_seed, 
instead of zero.