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. I'm also a little worried about how the hash functions will vary with different platforms. For example, if sizeof(long) > sizeof(std::size_t), then hash_value(long) might be weak for values which only vary in the higher bits. But I do want to stay close to your design for now. It's far better than what I would have come up with and it'll be good to get more experience of how well it works before considering any changes.
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. Daniel