On Monday 26 May 2008 03:53, Johan Torp wrote:
Frank Mori Hess-2 wrote:
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>&)
The thing is, this whole exercise started for me to see if it was possible to get rid of the public signal/slots on futures and replace it with just various waits on futures. Once we start adding callback functions to the future_select and future_barrier, which are executed on completion, it's really a sign of failure to me. I'd rather just leave the public slots on futures as that is simpler, more powerful, and no less dangerous.