Boost logo

Boost :

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).

Boost list run by bdawes at, gregod at, cpdaniel at, john at