On segunda-feira, 4 de março de 2013 22.00.34, Andre Somers wrote: > The point is to get notification when a job is done in the simples way > possible. Nothing more, nothing less, without having to check the status > of the future.
I understand what you want, but I don't want that. QFutureWatcher serves that purpose already. > I don't quite get that code at all, by the way. You seem > to be creating a QFutureWatcher on the stack, and still connecting to > its deleteLater method? It was pseudocode. It should have been: QFutureWatcher<T> *w = new QFutureWatcher<T>(); w->setFuture(QThread::start(...)); > I think the proposed API addition is actually quite natural. It is not > without precedent (QTimer::singleShot()), and would result in quite > simple, readable code. I disagree on both accounts. It's not natural: there is no precedent for taking two runnables outside of QtConcurrent's own reducing functions (map- reduce and filter-reduce). In that case, it serves a very specific purpose, in a domain where the concept is understood. And besides, that's the very module we're trying to replace. There's also no good API that takes two slots -- the only example I can think of is the horrible QDBusConnection::callWithCallback. And that one is made simpler and easier by QDBusPendingReply and QDBusPendingCallWatcher, two classes inspired by QFuture and QFutureWatcher. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
