|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-12-13 10:02:03
Alexander Grund wrote:
> That is actually a good point: Why are those requirements on the
> HashAlgorithm concept at all?
>
> The library is (mostly) about allowing to hash types, i.e. the framework
> surrounding `hash_append`.
> I understand that a specific way (currently being discussed here on the
> list) of construction is required for implementing `hash_append` for
> unordered containers.
>
> But besides that, why does the library require specific constructors at all?
Simplified, this asks "if we ignore the use cases that require seeding, why
does the library require that the hash algorithms support seeding?"
> For user convenience I can see `SeedableHashAlgorithm` as a subset of
> `HashAlgorithm` as a useful, additional concept to include in the library.
I've already answered this a few times. It's more ergonomic if all hash
algorithms support a consistent interface. This allows writing generic code
that can work with any algorithm. It allows switching from one hash
algorithm to any other without breakage. It also allows switching from
unseeded use to seeded use, or from use with uint64_t seed to use with
a byte sequence seed, without breakage regardless of the chosen hash
algorithm.
The idea here is to make switching from a less secure use to a more secure
use easy and painless.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk