On Wed, 14 Mar 2007 17:47:09 +0100, Giovanni Piero Deretta wrote:
Instead of going with generalized future composition, I've tried the route of 'wait_all(<future-list>) ' and 'wait_any(<future-tuple>)'
This is exactly what I personally would like to see. I don't relish the thought of digging out a return type or exception from a future<variant<float, string, tuple<int, double, bool> > >. I would just want something that wakes me up when dinner is ready and let me figure out which of my futures are valid or have failed, if I even care. wait(f1 || (f2 && f3)); might be nice syntax, does actually add functionality, and is simple enough as well. IMHO, all of this fancy blocking stuff should really be part of a larger event framework anyway. I'd love to throw a pair of futures together with a non-blocking file read and a listening UDP socket, and have the wait() yeild my thread to another task while I'm dreaming. But this is a far bigger problem than the future concept. add_callback() is my answer to disentangling future<T> from the general blocking problem.
I personally don't like the idea of having the future convert implicitely to its value type at all.
Nor do I. Herb Sutter has a good slide in his Concur presentation against it as well.
I agree. What about an optional<T> like interface for future<T>? future<some_type1> a = async_op1(...); some_type1 xa = *a; //may block if not yet ready
Personally, I just prefer no non-sense 'get()'. But I'm willing to implement whatever the general consensus is, and/or whatever gets past the C++ language committees. Braddock Gaskill Dockside Vision Inc