Re: [boost] [review] hash functions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-13 11:13:37

Dave Harris wrote:
> Fourthly, there seems to be a design philosophy behind the current
> proposal which is not stated explicitly in the documentation. It
> apparently favours some notion of safety over speed and hash quality,
> where "safety" means that different objects should have the same hash
> values if they look at all alike to someone possibly.

"Safety" is not the correct way to put it. "Predictability" or maybe 
"stability" is the proper word. This is also the reason to fix the 
implementation, not usually the case when aiming for standardization.

The problem is that hash functions vary wildly in quality. Leaving the 
default function unspecified (or implementation defined) is good if you are 
lucky and the implementation you happen to use is good. It's a tradeoff.

A fixed and predictable default means that you don't have to measure the 
quality of the hash function for every implementation to which you port your 
program. Your original tests are still valid.

The other side of predictability - that the hash function is not affected by 
types or the particular representation of a sequence of values - means that 
you don't necessarily have to re-run the performance benchmark of your 
unordered_maps when you refactor the key to use int[3] instead of struct { 
short, short, short }, or a wstring instead of a string.