Anthony Williams-4 wrote:
> After thinking more carefully on the problem I've realized it is
> implementable using condition variables. Here is a revised proposal, which -
> for now - excludes barriers.
Given wait_for_any and wait_for_all (see my latest revision), I don't
think we need these more complex composite classes in many cases, and
where we do they might be better implemented specifically for the case
at hand.
I agree we do not need this complex functionality in most cases. I too want to find a minimal interface which we can implement and get accepted into boost first, then we can add rich functionality - as Gaskill's proposal - on top of it. I hope we can find something much simpler than what I proposed without exposing the "completed callback". I fear that it might be difficult though.
I don't think your proposed interface is powerful enough to implement composed futures, but I might be wrong. For instance, how would you implement future operators with it?
future<bool> operator||(future<bool> lhs, future<bool> rhs);
Johan
