Peter Dimov wrote:
Tobias Schwinger wrote:
Example: let's say we have a disk-stored hash table and an in-memory hash table for caching. The same objects are stored but it is desirable to have two different hashing functions. Unfortunately boost::hash can only be used for at most one of them.
If I wanted to implement double hashing I'ld have to duplicate the whole facility (which may include writing a lot of "hash_value2" functions for a grown project) because there can be only one 'hash_value' per type which can only use one algorithm for combining the hash values, as the current design does not provide a way to get parametrization in there.
Looking at the source underlines this impression: hash_combine seems like a forgotten hard wired strategy in something that actually wants to be a facade.
The next generalization level isn't really about hash functions anymore.
I agree. That is, given that the "result" (or should I better say "context" here ?) is not restricted to std::size_t. If it's generic enough to factor it out, it's even better, isn't it ?
You are asking for a generic visitation interface where you give a visitor to a container (or a compound type with nonambiguous state*) and the container applies the visitor to each of its elements. This facility is very useful (not only for hashing, but for serialization, stream output, and others) but I don't believe that it belongs in a utility hash function library.
One could argue that it belongs into Boost to implement things like hashing on top of it before they are written... ...but I won't ;-). Besides we should have hashing in ASAP, at least for political (Java) and housekeeping (so other libraries have a default for their template parameter lists) reasons. Regards, Tobias