<snip, Marc & Giuseppe talk 'std' and 'Qt' hashing> Marc: > I know Howard's ideas about hashing, and I agree with them. In Qt, we > largely > ignore the issue of hash collisions for a given type and just hash its > members, combining with boost::hash_combine, and hope for the best. As > such, > the problem described in Paragraph 5 of > https://isocpp.org/files/papers/n3980.html#Solution1B, if it is, indeed, > the > one you're referring to, is the same for qHash() and std::hash. Only a > Hinnant-like hashing interface that takes the hash function as a parameter > would solve that. > > Are you suggesting to skip supporting std::hash and go directly to > providing > Hinnant's interface in Qt instead? >
I'm party-crashing the discussion, but +1. (1) Skip std::hash, it's the wrong interface. (2) Use a transactional hash interface (very performant and composable) We implemented the Hinnant-style interface a long time ago throughout a very large codebase, it works best when consistently supported across the codebase, IMHO it's a vastly superior way to go. For the casual reader, this implies a "transactional" approach to hashing: (1) "Start/init" the hash (2) Go nuts accumulating state into the hash (3) Finalize the hash (for example, can be "lazy" when hash-value is extracted) The problem with "std::hash" is that it lumps all three steps into one step, which is horrible and expensive in many/most real-world applications requiring hashing of non-trivial state. The Hinnant-style interface works great when all APIs take a "QtHashBuilder" (or whatever). Qt has tons of experience with consistent APIs like that, for example, see recent discussions on QStringBuilder or similar. --charley
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
