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).