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

[Thiago Macieira]

On Monday, 3 June 2019 02:26:05 PDT Lars Knoll wrote:
> > == Java-style iteration
> > (https://codereview.qt-project.org/c/qt/qtbase/+/262344) ==
 
> > It's very easy to write quadratic loops with it.remove(), and a review of
> > Qt code has shown that some users still use container.remove(), which is
> > just as unsafe as with STL iterators. I also noted between 100b/loop and
> > 5KiB for four loops of text size savings.
> 
> I’m a bit torn here. On code review I gave a +1 on deprecating them, but I
> see that this could lead to a lot of porting effort on user code that makes
> extensive use of them. And the problem is that the porting can be
> non-trivial in cases where the list gets modified while iterating. So I
> think we should most likely keep them for Qt 6.

Those are entirely-inline classes, so they don't take space in the library. 
They've also been completely unchanged for years, so the maintenance cost is 
minimal.

I agree with deprecating but keeping in 6.x.

> > == QRegExp ==
> > 
> > Is QRegularExpression good enough these days? :)
> > 
> 
> I’m in favour of deprecating and moving it into a Qt5Support library. As
> pointed out, qmake will need it.

Possibly a library specifically for QRegExp, like we did for QHttp in 5.0.

> > === QAtomic -> std::atomic ===
> > 
> > It already is just a thin wrapper around std::atomic, so there's not much
> > point keeping it.
> 
> Except that a simple search and replace will change semantics of load(). And
> I think that’s not quite acceptable, given that atomics are in quite a few
> cases used for performance sensitive code paths.

A semantic replacement could be used to refactor the code from load() → 
load(std::memory_order_relaxed) and loadAcquire() → load().

I wouldn't suggest adding a wrapper that does the mapping. Because we already 
have one: that wrapper *IS* QAtomicInteger, which already wraps a std::atomic. 
So either we perform a global, semantic search-and-replace, or we just do 
nothing.

> > === QMutex / QReadWriteLock -> std::*mutex* ===
> > 
> > It has too many responsibilities. Where the std knows many different mutex
> > classes, Qt folds everything into just two.
 
> > We probably need to keep QRWL around a while longer, since C++ added
> > shared_mutex only in C++17.
> 
> The only problem I see with QMutex is that it implements both a recursive
> and non recursive mutex in one class. I would consider splitting that up.

Already prepared for that. I haven't performed the change, but it's easy to 
do.

I recommend adding QRecursiveMutex right now in Qt 5, with the only difference 
from QMutex being that it changes the default constructor. That way, code can 
begin porting, as we deprecate the non-default constructor.

QRecursiveMutex will derive from QMutex. I hope that's not a problem. Whether 
QMutex::lock() can be poor-mans-virtual and perform a recursive lock is up for 
discussion.

As a benefit, neither QMutex nor QRecursiveMutex will allocate memory on 
Linux.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products