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

[Olivier Goffart]

On 29.05.19 12:53, Mutz, Marc via Development wrote:
> == MT plumbing ==
> 
> Let's make use of the std facilities to enable checkers such as TSAN to work 
> without hacks. It's not Qt's business to reimplement threading primitives.

Normally, checkers such as TSAN work out of the box.
But they kind of require Qt to be build with TSAN.

> Probably need to keep some stuff around, like QThread, because of the 
> interaction with event processing, but before we add a lot of time making the 
> following classes play nice with the std, let's perspectively remove them:

I think we could get rid of QThread and get along with std::thread and 
std::thread::id
We would have to keep a std::unordered_map<std::thread::id, QThreadData>, but 
that might be a bit difficult. (What happens if we do 
QObject::moveToThread(std::thread::id), and thread was already finished.
We can mandate that an the thread has a Qt eventloop, so we can use TLS 
destructor to clean the map. But if we still access the thread handle after the 
thread terminate, we have a problem)

> === QAtomic -> std::atomic ===

I agree.

> === QMutex / QReadWriteLock -> std::*mutex* ===

The implementation of QMutex, and especially QReadWrtieLock is much more 
efficient that one of most standard library.

See https://woboq.com/blog/qreadwritelock-gets-faster-in-qt57.html

QMutex::lock  and QMutex::unlock  should be made inline, and then there should 
be less problems with TSAN (I assume the problem is that TSAN does not "see" 
the atomic operation when a Qt user uses QMutex and Qt itself was not compiled 
with TSAN,  and this is what you refer as work without hacks)

> === QMutexLocker -> std::unique_lock ===
> 
> 1:1 replacement in the vast majority of cases. unique_lock has a lot more 
> features (movable, adopting a locked mutex, not tied to any particular mutex 
> class, ...)

Yes, with C++17 automatic template deduction, it is the same.

> === QWaitCondition -> std::condition_variable(_any) ===

Yes.

> == QQueue / QStack -> std::queue, std::stack ==
> == QSharedPointer / QWeakPointer -> std::shared_ptr/weak_ptr ==
> == QSet / QHash -> std::unordered_set/map ==
> == QMap -> std::map ==

Probably a good idea to get rid of that.
Could be kept as a third party optional library in the "Done" state, for those 
user who like the API so much better. But it should be part of the Qt API.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org