Re: [boost] Re view Request: future library (N2561/Williams version)

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-05-25 22:53:56

On Friday 23 May 2008 10:50, Johan Torp wrote:
> Yes, I'm thinking of a passive function which doesn't have an internal
> thread associated with it. One that is evaluated lazily as soon as
> someone is interested in it.
>
> I think this could be very useful, do you? 

Hmm, so it does seem that I would need something like what you've been 
suggesting to convert my scheduler over to waiting on futures instead of 
relying directly on signals/slots.  Or, at least I would minimally need to 
be able to construct a future<X> from and future<Y> where X and Y are 
unrelated types by specifying a passive conversion function.  So for 
example, when 

future<Y> fut_y; 

becomes ready, the future<X> would become ready with the value returned by 
conversion_function(fut_y.get()).

The more general solution that accepts multiple arguments would be like 
future_barrier, except it would accept an additional first argument that 
is the conversion function, and it would return a future<R> where the 
value R for the returned future is obtained by calling the conversion 
function with all the values from the input futures.  So it might look 
something like

R combining_function(const T1 &t1, const T2 &t2, ..., const TN &tn);

future<T1> f1;
future<T1> f2;
//...
future<T1> fN;

future<R> result = future_combining_barrier(&combining_function, f1, 
f2, ..., fN);