From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-03-11 11:59:00
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk