On sexta-feira, 22 de fevereiro de 2013 15.28.44, Corentin Jabot wrote: > 2013/2/22 André Somers <[email protected]> > > > If only QFuture allowed you to connect... Unfortunately, it is not a > > QObject > > Oh yeah, I almost forgot that bit. And somehow it looks like the core issue. > I wonder why by the way: > > We could have something like QObject <- QFutureBase (with all > requiered signals/slots) <- QFuture<T> > or is there something I'm not seeing ? > > Of course now its too late, but we could introduce something new, like > QFutureObject ?
That's QFutureWatcher. The fact is that any QObject that is returned from those functions -- if any -- must belong to the calling thread. That implies the necessary guarantees in terms of signal emissions. For example, if the functions return a QObject pointer, a signal-signal connection from the actual target object's finished() signal to the returned object's finished() will apply the necessary queueing semantics. That also speaks against returning a QThread*. -- 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
