On Tue, 04 Jun 2019 22:41:31 +0200 "Mutz, Marc via Development" <development@qt-project.org> wrote:
> That QThread is-a QObject has caused problems in the past. How to use > QThread correctly has been the source of much discussion (e.g. > https://blog.qt.io/blog/2010/06/17/youre-doing-it-wrong/), and any > thread can have an event loop via QEventLoop. But, yes, QThread probably > needs to stay around longer. That shouldn't mean it does so forever. I > think std::thread is much easier to use and understand, and with > QEventLoop supporting it already, I don't feel much attachment to > QThread anymore. QThread should on the contrary stay "forever". QThread has no flaw and doesn't match your (good) recent definition of a need for deprecation. On the contrary, it has a more capable interface than std:: thread, thanks to its QObject inheritance. IOW, it connects perfectly inside a Qt application. I believe Qt users expect this consistency. And concerning the QThread link you mention, it should be compensated by Olivier Goffart's paper https://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html Having two ways of doing something can be seen as flexibility rather than design flaw. Several of your proposals are about removing some "very-Qt" classes, to replace them by std classes. On the contrary, I believe these Qt classes, when they have no flaw, should better continue to be improved compared to std. Philippe _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
