[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
olivier at woboq.com
Wed May 29 17:13:51 CEST 2019
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
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 ===
> === QMutex / QReadWriteLock -> std::*mutex* ===
The implementation of QMutex, and especially QReadWrtieLock is much more
efficient that one of most standard library.
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) ===
> == 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.
Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
More information about the Development