Peter Dimov-5 wrote:
There's no question that the future-based interface can be safer and more convenient. But this doesn't necessarily make it "the" low-level interface on top of which one can (or must) express all other interfaces.
I wasn't suggesting this, for instance I doubt Microsoft will be unwilling to rewrite their message pumps to use futures internally :) I wonder if all existing architectures can somehow be adapted to work smoothly with futures - without the future-complete callback. Either by intrusively adding explicit support for futures or by writing some simple helper functions which maps futures into the main flow control. For instance, a message passing architecture might provide something like this: active_object a; future<X> x = a.do_foo_async(); // Can this be implemented? repost_as_message_when_ready(message_channel, x, bind(&make_foo_complete_message, _1)); If futures can be integrated into any architecture, I imagine they can become "the glue" between user architecture and various asynchronous libraries. Does this seem lika a reasonable goal for futures? Peter Dimov-5 wrote:
The callback-based interface, on the other hand, can be difficult to use, but both future-based and message-based interfaces can be built upon it.
A future-based interface built on top of a callback interface doesn't seem to suffer from the deficiencies you list, and neither does a message-based interface (given an appropriately powerful and robust message-passing framework in which to express it.)
You're right. Maybe the more powerful but more dangerous callback-style interfaces is better in many situations rather than forcing futures on the users. Future return value-interfaces has a certain elegancy/clarity to them which I guess I'm drawn to :) Johan -- View this message in context: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-inte... Sent from the Boost - Dev mailing list archive at Nabble.com.