[Development] QHash for Qt 6

[Giuseppe D'Angelo]

Il 20/12/19 12:20, Philippe ha scritto:
> std::unordered_map is before all an interface and the implemenation varies according to the library supplier.
> And this, potentially much more eg. than std::vector.
> And X-Platorm Qt users would expect performance consistency I guess.

Devil's advocate, again: this also applies, say, to std algorithms. Or 
operator new. Should we stop using them and roll our own?

(Specifically: std::unordered_map is so over-specified that there is, in 
fact, only one implementation possible. I would be surprised to see 
drastic performance changes across platforms.)


> The research of the "ultimate map" is a hot topic. There is of course not a single implementation that have all benefits.
> But Lars' implementation is something that works in many scenarios and that would bring value to Qt users.
> 
> The performances are not "just a bit better" than with the Qt 5
> or std implementations, there are way better, if you look at the
> diagrams.

I didn't disagree at all with the performance claims...


> And that's the whole point of Lars' proposal.

And my point was that Qt shouldn't _really_ bother reinventing something 
already easily available elsewhere. Usage of a "fast hash" internally to 
Qt doesn't mean we provide that API to our user (hello, QFlatMap; or 
std::vector usages all over Qt internals.).

My 2 c,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20191220/485cd3f5/attachment.bin>