Evolving Boost.ContainerHash

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-10-12 23:25:25

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_map<std::string, int, boost::hash<std::string>> map(
    0, boost::hash<std::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.