Boost logo

Boost :

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-06-03 05:56:47

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

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 :)


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at