On Mar 14, 2007, at 4:05 PM, Braddock Gaskill wrote:
On Wed, 14 Mar 2007 15:50:34 -0400, Howard Hinnant wrote:
You could call this on a promise: result(f) and a promise_functor<R, F> would be returned as the result (I'm not at all very attached to the name promise_functor). Executing that functor would be roughly equivalent to setting the promise:
I believe this is similar to the 'class task' wrapper that Peter Dimov proposed in N2096 at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2096.html
<nod> You caught me! :-)
I think easy to use wrappers are a vital part of implementing future. I'm not sure I see a great advantage to putting the wrapper functionality directly within the promise class constructor though.
Actually I was proposing a promise operator()(F) which returns the wrapper, thus keeping the wrapper data (the F) out of the promise class. I.e. promise_functor is Peter's class task. And promise is roughly Peter's class task with the functor stripped out of it. The functor, the promise, and the future all need to point the same underlying return_value. By having the promise create the return_value, and then subsequently responsible for producing the future and functor (or equivalently the future and functor are constructed from the promise), you ensure that all three "handles" point to the same return_value. The template type of the functor is clumsy to have to deal with directly, and so it is best if that type is deduced somewhere, such as in a functor factory function, or a templated promise::operator(). -Howard