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

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.