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... Sent from the Boost - Dev mailing list archive at Nabble.com.