Boost logo

Boost :

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
        template<class T>
        void push(const future<T> &f, function<optional<ResultType>(T)>& eval);

template<class ReturnType>


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at