[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
giuseppe.dangelo at kdab.com
Thu May 30 20:57:24 CEST 2019
On 30/05/2019 20:20, Thiago Macieira wrote:
>> I like that idea. Maintains our API and semantics while removing our
> 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 | 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...
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
More information about the Development