[Development] What kind of airplane we want to build?
Thiago Macieira
thiago.macieira at intel.com
Thu Jan 21 17:33:05 CET 2016
On Thursday 21 January 2016 10:02:41 Marc Mutz wrote:
> Having had to teach this stuff to customers when this came out in Qt 4, I
> can tell you this distinction will not register with most Qt-newbies.
> Allowing such ease of wrong API use is against my reading Qt's own design
> principles ("make it hard to use an API incorrectly"). That QThread is a
> QObject is a bug, not a featuee. It would be better as a non-QObject,
> adding QThreadWatcher a la QFutureWatcher to enable singals. In that case,
> QThread can be replaced with std::thread without much loss of generality.
It wouldn't be QThread *Watcher* because it needs slots too, like quit() and
terminate(). It would be more like QThreadManager. At that point, it's QThread
again.
I agree with you that we should make it harder for people to misuse. With the
advent of lambdas, we can easily add a QThread::makeThread(lambda) and
deprecate completely the overriding of virtual run(). That in turn discourages
adding signals and slots.
> How we'd represent a thread if QThread was dropped is a different question,
> but easily resolved once we get there (QThreadHandle, or even re-using
> QThread, but not as a QObject subclass).
I don't see the point. We already have a threadId(). If we want to return a
handle, I would call for it to be std::thread. That would imply replacing our
backends with std::thread.
Maybe in 2020.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list