[Development] Evolving Qt's multithreading API

Robert Knight robertknight at gmail.com
Fri Feb 22 17:07:57 CET 2013


> However, std::function and std::bind were already in tr1,
> which AFAIK is already supported by all the compiler we support (Tier1 +
Tier2)
> (MSVC 2008 and gcc 4.2 have it)

For VC 2008 it is part of an add-on pack [1], but it is available.

> We could have something like QObject <- QFutureBase (with all
> requiered signals/slots) <- QFuture<T>
> or is there something I'm not seeing ?

QObject is heavy - in terms of memory usage, construction/destruction cost
etc. - if there are scenarios
where you are creating thousands of such objects, this could be a problem.

Regards,
Rob.

[1] http://www.microsoft.com/en-gb/download/details.aspx?id=6922


On 22 February 2013 14:28, Corentin Jabot <corentin.jabot at gmail.com> wrote:

> 2013/2/22 André Somers <andre at familiesomers.nl>
> > 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 ?
>
>
> Corentin
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130222/ef60df07/attachment.html>


More information about the Development mailing list