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 _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
