I haven't downloaded and compared your and Anthony's implementation yet so forgive me if I misunderstand anything. Braddock Gaskill-2 wrote:
1) First - future<T>::add_callback(f).
add_callback is a hook called when the future is fulfilled. End users probably shouldn't have to touch it, but framework authors (who write schedulers, asio, co-routines, etc) will DEFINITELY need it.
add_callback() enables the following:
-Future Operators ((f1 && f2) || (f3 && f2) etc) - With add_callback, custom future_operators can be written by users.
Isn't it more natural to consider the promise object a signal and the future object a slot? If we exposed a mechanism to wait for multiple promises we could implement promise operators instead. ((p1 && p2) || (p3 && p2) would create a new promise which internally listens to multiple promises. A binary future which takes two promises and a binary operator would be enough for this example. For efficiency reasons we'd probably need some mechanism which can add arbitrarily many promises at runtime. Braddock Gaskill-2 wrote:
2) Second - Lazy Futures.
This would correspond to lazy promises. Best Regards, Johan -- View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29... Sent from the Boost - Dev mailing list archive at Nabble.com.