Re: [boost] Common future base class (was Re: Boost.Fiber mini-review September 4-13)

Le 06/09/15 15:14, Hartmut Kaiser a écrit :

...

The problem exist already for any library proposing a standard future implementation. How can this new implementation works with a standard implementation. This is the case for Boost.Thread, HPX, Boost.AFIO, Boost.Fiber, or your own implementation. What I meant is that we need to change the standard to be able to solve this problem, as the standard don't take it in account. I believe the solution to is not so much to change (std::)future, but to push forward 'await' instead. It already has (most) of a future-type-agnostic synchronization mechanism specified. You said (most). What is missing yet? Granted, the proposal will change, but I'm certain it will get into C++ in the C++17 timeframe. The 'await' allows to rewrite when_all, etc. such that it works for any combination of input futures. Here's a sketch (sans decay, etc.):

namespace foobar { template <typename Future...> requires(is_future<Future>)... future> when_all(Future &&... f) { (await f)...; return make_tuple(std::forward<Future>(f)...); } } Clever and simple, await and variadic expansion allows this simple implementation for boost::wait_all. Does this work already?

This includes already a change to the standard, as when_all must work for any FUTURE like and off course needs await to make it simple Have you also a clever and simple implementation for when_any? Wouldn't it need more changes to the standard? These is what I have in mind when I said "the standard don't take it into account " at least not now.

i.e. every library which exposes its future type provides this trivial implementation of when_all(), etc. It can consume any future from any other place, however. Ok, so the user choose the future result by using a specific qualified overload, isn't it?

auto r = foobar::when_all(....) Even if the implementation seems simple, it is weird to have to do it, but I could live with that. Vicente