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

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-26 03:53:28

Frank Mori Hess-2 wrote:
> 
> That reminds me, I've been so focused on trying to make future_select work 
> with heterogeneous input futures, that I neglected the homogeneous case.  
> That is, future_select() always returns a future<void> even when all the 
> input futures have the same type.  And after all, maybe supporting the 
> homogeneous case is good enough.  For example, in my use case I've already 
> taken care to type-erase the method requests in the schedulers down to a 
> uniform type, because the scheduler needs to store them in a container 
> anyways.
> 
> So the only other thing I'd need is some kind of explicit future container 
> that can be re-used to "wait for any" repeatedly without rebuilding the 
> entire set of futures each time.  Maybe something with a queue-like 
> interface:
> 
> template<typename T>
> class future_selecter
> {
> public:
> 	future<T> front();
> 	void pop();
> 	void push(const future<T> &f);
> };
> 
> where the future returned by front() would have the value from the next 
> future in the future_selector to become ready.  pop() would discard the 
> completed future previously being returned by front(), so front() can 
> return a new future corresponding to the next one to complete.
> 

I still think solving the heterogenous case is worthwhile. The interface
isn't much more complicated, it could look like this:

template<typename ResultType>
class future_selecter
{
public:
        template<class T>
        void push(const future<T> &f, function<optional<ResultType>(T)>& eval);
};

template<class ReturnType>
future::future(future_selector<ReturnType>&)

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