Op 4-3-2013 21:21, Thiago Macieira schreef: > On segunda-feira, 4 de março de 2013 17.25.35, André Somers wrote: >> QFuture<T> runFunction(QFunction<T> then, QFunction<T> main); >> QFuture<T> runFunction(QFuntion<void> then, QFuntion<T> main); >> QFuture<T> runFunction(QFunction<T> main); > I think this is going too far. If you want to chain jobs, we need a more > complex job tracker. That's what ThreadWeaver is trying to do. But we need to > solve a simpler problem first. > > And besides, you can always do: > > QFutureWatcher<T> w = runFunction(...); > w.connect(&QFutureWatcher<T>::finished, []() { other function goes here }); > w.connect(&QFutureWatcher<T>::finished, w, &QObject::deleteLater); The point is not to chain jobs. Indeed, that is what threadweaver is doing. I am sorry if I did not make the point clear. The point is not to create complex chains (or really: networks) of jobs. ThreadWeaver already supports that use case. Still, I suppose you could do something like that. The lines I wrote however were not meant as a chain, just as different versions of the same method with a then method taking a parameter of the type of the function, a then method without a parameter and a call without any then argument.
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. The way I understand QtConcurrent, the work is started immediately and may finish at any moment. So, by the time I create the QFutureWatcher and added the connect, the work may already be done. Right? That means that you have to check for that as well, or you risk missing the finished signal. See the discussion on the trampoline object elsewhere in this thread. You'd avoid that by passing what you want happening directly to the invocation to QtConcurrent. The resulting code using a then argument would be much simpler than what you post above. 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? Also, which method directly returns a QFutureWatcher? The QtConcurrent I'm familiar with returns a QFuture<T>, which you can assign to a QFutureWatcher. 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. It also doesn't create big constraints on the type of object returned from these functions: there is no need for them to be QObjects themselves. If you want more control or need more information, you'd still create a QFutureWatcher of course, as it provides more information than a simple "done". André _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development