[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