[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