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