[Development] How to include Standard Library headers from Qt ones?
marc.mutz at kdab.com
Sun Apr 16 13:26:00 CEST 2017
On Saturday 15 April 2017 16:10:16 charleyb123 . wrote:
> <snip, Marc & Giuseppe talk 'std' and 'Qt' hashing>
> > 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())?
> 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
> 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
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
KDAB - The Qt, C++ and OpenGL Experts
More information about the Development