[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

Thiago Macieira 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
> wrote:
> > 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
> 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.

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 mailing list