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

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-12-12 14:10:42

12 décembre 2024 à 14:22 "Peter Dimov" <pdimov_at_[hidden] mailto:pdimov_at_[hidden]?to=%22Peter%20Dimov%22%20%3Cpdimov%40gmail.com%3E > a écrit:

> 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