From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-09 09:09:20
Daniel James wrote:
> Peter Dimov wrote:
>
>> It is a deliberate design decision that the algorithms are fully
>> specified. The goal is precisely to not allow you (as an
>> implementor) to change them.. ;-)
>>
>> As usual, this is a tradeoff between giving more freedom to
>> implementors to improve the behavior and giving more portability
>> guarantees to users. Varying the hash function can lead to dramatic
>> changes in performance and not specifying the exact algorithm will
>> mean that an application using the default hash functions would need
>> to be benchmarked again after every change of the standard library.
>
> Yes, I agree for the final standard, but we're not there yet.
It doesn't matter. The choice is between documented algorithms and
undocumented algorithms, not between the specific algorithms I specified and
something else. I argue that the algorithms need to be documented.
>> Of course the fact that hash_range gives the same result as
>> hash_value on the corresponding container is no accident, either.
>
> Yes, the reason that this came up, is because this wasn't true for
> Jeremy's original implementation. But I think his hash function for
> strings was faster, which might be desirable.
A hash function is only faster when the corresponding operation, built
around it, is faster. Benchmarking a hash function in isolation is
pointless. For example, one well-known implementation has (had?) a
tremendously fast hash function which leads (lead?) to their hash_map being
four times slower than a std::map for a real-world set of keys.
That said, I don't see why this is an argument in favor of making hash_range
return something else. The whole point of providing hash_range is to allow
the user to write a hash function for their custom string (or container)
type that returns the same result as the standard hash function for strings
(or other containers).