[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
thiago.macieira at intel.com
Thu May 30 20:20:49 CEST 2019
On Wednesday, 29 May 2019 08:22:28 PDT Allan Sandfeld Jensen wrote:
> On Mittwoch, 29. Mai 2019 15:33:23 CEST Giuseppe D'Angelo via Development
> > Il 29/05/19 12:53, Mutz, Marc via Development ha scritto:
> > > == QSet / QHash -> std::unordered_set/map ==
> > >
> > > I'd really like to see these gone. Mainly to free up their names for OA
> > > hash containers, something that the STL doesn't, yet, have.
What's an OA hash container?
> > I don't think this is realistically possible. What I would suggest, to
> > bring the maintenance burden down to a minimum, and increase our
> > compatibility with stdlib to a maximum, is have QHash/QMap to be a CoW
> > wrapper for std::(unordered_)map . The inner data structure should be
> > exposed to the user, allowing for deep integration between stdlib and Qt.
> 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.
Our discussion in QtCS a year or two ago was that we would keep these classes
as wrappers around the std ones. Which brings me to:
> == 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.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Development