Re: [hash2] Difference from paper: HashAlgorithm interface vs. function object

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-12-12 15:05:38

On 12/12/24 16:22, Peter Dimov via Boost wrote:
> Julien Blanc wrote:
>> Le mercredi 11 décembre 2024 à 19:31 +0200, Peter Dimov via Boost a écrit :
>>> You've already stated that you don't think copy construction should be
>>> required. But copy construction is required by the current
>>> implementation of hash_append_unordered_range.
>>
>> The way you phrase it make it sounds like it could be implemented without
>> requiring copy construction. Is that poor understanding from my side?
> 
> I feel like I already answered this question.
> 
> The alternative mechanism given in N3980, constructing a temporary std::set
> from the unordered set elements, then hashing that, is wildly impractical
> for obvious reasons, performance and otherwise.
> 
> Using default-constructed instances of the hash algorithm, instead of copies,
> makes the hashing seed-independent, which means that a way to engineer
> collisions will work regardless of the seed used.

But the original hash algorithm h does depend on the seed, and so does
its final result.

Conceptually, hash_append_unordered_range has the effect of applying h
to the input sequence ordered in a specific (though unspecified) way.
That is, regardless of the seed used to initialize h, the input data of
h does not depend on the seed. Again, conceptually, this looks
equivalent to the case when each h2 that is used to hash each element of
the sequence does not depend on the seed (i.e. produces a value that is
solely dependent on the hashed element).