Boost logo

Boost :

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-23 10:50:47

Frank Mori Hess wrote:
> How about an additional future_select overload which accepts two
> boost::shared_container_iterators as arguments, and returns a
> future<shared_container_iterator>? The returned iterator would point at
> the
> future which is ready or has an exception. Then the caller could use the
> returned iterator to erase the element from the container before calling
> future_select again. The shared_container_iterator would insure the input
> container of futures doesn't die before the return future becomes ready.

That would restrict users to put their futures in a container created as a
shared_ptr, right? Williams' shared_future already has reference semantics
and could be copied. unique_futures should somehow be moved in and owned by
the composite future as nobody else should look at it's result. Not sure
what is best here.

Frank Mori Hess wrote:
> Having a future execute a callback at the end of a wait completing seems
> only
> marginally useful to me. I'm not sure it's worth the complication.
> - snip -
> That's exactly what poet::active_function does, or did you have something
> different in mind?

Yes, I'm thinking of a passive function which doesn't have an internal
thread associated with it. One that is evaluated lazily as soon as someone
is interested in it.

I think this could be very useful, do you? I haven't worked very much with
active objects so your 5 cents are probably worth more than mine :) But yes,
it requires some complexity - probably comparable to that of


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