On Saturday 15 April 2017 16:10:16 charleyb123 . wrote: > <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)
I'm sympathetic to this. The problem I see is that while adding hash_append() overloads is easy to do, and requires no header included, some of the value of Hinnant's proposal is std::is_uniquely_represented, which, as a type trait, needs some header to provide a primary template. Is there some definite reference implementation that we could check for (with QT_HAS_INCLUDE())? Thanks, Marc > 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 -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
