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

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-16 05:23:08

Frank Mori Hess wrote:
> 
> Ah, yes it seems like some kind of composable future_switch and
> future_barrier 
> could work quite well for my use case.  Do they actually need to be
> classes 
> though?  What if they were just free functions for example
> 
> future<void> future_barrier(const future<void> &a1, const future<void>&
> a2, ... , const future<void> &aN);
> 

If we want to support dynamically adding futures to future_switch and maybe
future_barrier a free function won't suffice. However I believe these
functions are really useful and should be implemented on top of the proposed
mechanisms.

template<class ReturnType, class Arg1, class Arg2>
future<ReturnType> barrier_compose(const future<Arg1> &a1, const
future<Arg2>& a2, 
                                                   const
function<ReturnType(Arg1, Arg2)>& compose);

Johan
-- 
View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-tp16600402p17270732.html
Sent from the Boost - Dev mailing list archive at Nabble.com.