From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-05-26 13:26:48
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.