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.