I've been thinking of updating and evolving Boost.ContainerHash, so I
e-mailed Daniel James to see what his thoughts on that are. He says he's
not going to come back to it, since he's moved on from C++. (Why would
anyone do so is beyond me. :-))
More specifically, what I'm envisaging is updating boost::hash to take a
seed:
template<class T> struct hash
{
hash(); // as before
explicit hash( size_t seed );
size_t operator()(T const& v)
{
return detail::hash_combine(seed, hash_value(v));
}
};
The public hash_combine then becomes:
template<class T> void hash_combine( size_t& seed, T const& v )
{
return hash<T>(seed)(v);
}
This allows passing seeded hashes to unordered containers, without
any changes to the latter:
std::unordered_mapstd::string> map(
0, boost::hashstd::string( 0x12345678 ) );
Seeding user-exposed hash tables is a good security practice which
prevents (or makes less likely) some DoS attacks.
The combiner function, detail::hash_combine, will also need to be
updated to something that is state of the art for 2021, rather than for
2004. (ContainerHash is already using a more modern implementation
of hash_combine, but not in all cases.)
The implementation can be cleaned up by removing the C++98 era
workarounds for compilers not supporting partial specialization,
function template ordering, or argument-dependent lookup. The
documentation is also due to a refresh, as the mentions of TR1 are
no longer relevant.
I also think that Boost.ContainerHash should just be renamed to
Boost.Hash as that's what it is - it defines boost::hash.
So, I am thinking of taking over ContainerHash and doing all that,
if there are no objections.
