Hi, On 30/05/2019 20:20, Thiago Macieira wrote:
I like that idea. Maintains our API and semantics while removing our implementation.We may not even need CoW for those. Something to be benchmarked to see how well we do. If we skip the CoW, we gain a bit in performance by removing a level of indirection to the data.
Part of the reasoning was that QHash/QMap still jump through memory, so the extra indirection to keep CoW wouldn't drastically worsen things.
I would be against dropping CoW. It's been part of Qt's contract since forever and removing it has too far-reaching consequences.
== qHash() -> std::hash == Suggested by Lars in https://codereview.qt-project.org/c/qt/qtbase/+/261819. To be precise, he's suggesting to specialise std::hash and have qHash() call std::hash.qHash() choices should be in tandem with QHash choices. If we make QHash wrap std::unordered_map, then qHash gets deprecated. If QHash's implementation stays, then so does qHash.
qHash can get deprecated, but I again would be against a source break. We'd need to find some template magic such that qHash is used, if present; otherwise std::hash is used.
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: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
