[Development] How to include Standard Library headers from Qt ones?

[charleyb123 .]

<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170415/a6999962/attachment.html>