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 | [email protected] | 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
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
