12 décembre 2024 à 14:22 "Peter Dimov"
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.
Thanks for clarifying this again, then.
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.
Yes, this one is pretty obvious.
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.
This one is less obvious. That's a design motivation that at least should be found in the documentation. The rationale in N3980 for copy of hash algorithm was performance (btw, i don't really buy the performance argument, it seems like a pretty unusual case), completly unrelated to unordered containers. Regards, Julien