Boost logo

Boost :

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.




Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk