Yes, that is what I meant to imply. Don't wait, but look at what is currently
on the table, either for ideas, or to add ideas to.
Implementing something that works is a great way to influence the standard.
-Original Message-
From: development-bounces+tvaneerd=rim@qt-project.org
Nope.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3378.pdf
-Original Message-
From: Olivier Goffart [mailto:oliv...@woboq.com]
Sent: Friday, November 16, 2012 6:58 PM
To: Tony Van Eerd
Cc: development@qt-project.org
Subject: Re: [Development] The future of QFuture,
On domingo, 18 de novembro de 2012 12.26.25, Sze Howe Koh wrote:
On 16 November 2012 07:39, Thiago Macieira thiago.macie...@intel.com
wrote:
I'd like to see someone give TBB a Qt-ish API wrapper.
How would the licensing work if, say, a Qt Commercial customer uses
Qt-wrapped TBB, encounters
On domingo, 18 de novembro de 2012 12.36.25, Sze Howe Koh wrote:
Speaking of which, is there a reason why QFuture* classes are still in
Qt Core? QFuture is meant to be created through QtConcurrent
functions, if I'm not mistaken.
Are still is wrong. They were moved back to QtCore, so we could
On 18 November 2012 20:29, Thiago Macieira thiago.macie...@intel.com wrote:
On domingo, 18 de novembro de 2012 12.26.25, Sze Howe Koh wrote:
On 16 November 2012 07:39, Thiago Macieira thiago.macie...@intel.com
wrote:
I'd like to see someone give TBB a Qt-ish API wrapper.
How would the
On 16 November 2012 07:39, Thiago Macieira thiago.macie...@intel.com wrote:
I'd like to see someone give TBB a Qt-ish API wrapper.
How would the licensing work if, say, a Qt Commercial customer uses
Qt-wrapped TBB, encounters a problem involving upstream TBB, and needs
paid support? Would Digia
On 14 November 2012 19:17, Sorvig Morten morten.sor...@digia.com wrote:
I think what QtConcurrent really needs is a plan. What do we want it to be?
There are several options, and I'd like to offer the null option:
QtConcurrent is done. The implementation is not good enough to be used as a
On Thursday 15 November 2012 23:08:39 Sze Howe Koh wrote:
Thiago also hinted that QtConcurrent development is being minimized
(...we're not developing QtConcurrent anymore and shouldn't be
spending any effort on this than necessary to keep it working [1]).
That suggests that the dev team has
C++1y (ie whatever the next standard might be called) will likely have even
more threading options.
Including an executor model where you queue up std::functions to be run on
background thread(s). But the background threading is configurable by the
fact that the executor object isn't
On sexta-feira, 16 de novembro de 2012 23.46.32, Tony Van Eerd wrote:
C++1y (ie whatever the next standard might be called) will likely have even
more threading options. Including an executor model where you queue up
std::functions to be run on background thread(s). But the background
On Friday 16 November 2012 23:46:32 Tony Van Eerd wrote:
C++1y (ie whatever the next standard might be called) will likely have even
more threading options. Including an executor model where you queue up
std::functions to be run on background thread(s). But the background
threading is
On 15 November 2012 04:31, Sune Vuorela nos...@vuorela.dk wrote:
On 2012-11-14, Christian Kandeler christian.kande...@digia.com wrote:
On 11/14/2012 12:17 PM, Sorvig Morten wrote:
QtConcurrent is done. The implementation is not good enough to be used as a
base for further development.
Can
QThread:
- needs new docs (coming in 5.0)
- often misused (you're doing it wrong)
- results in too many dedicated threads (typically)
- or threads created/destroyed too often
QtConcurrent::run()
- I thought this was a better alternative for one shot tasks
- now it sounds like QtConcurrent is not
On quinta-feira, 15 de novembro de 2012 21.07.09, Tony Van Eerd wrote:
QThread:
- needs new docs (coming in 5.0)
- often misused (you're doing it wrong)
- results in too many dedicated threads (typically)
- or threads created/destroyed too often
QtConcurrent::run()
- I thought this was a
14 matches
Mail list logo
