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

Subject: Re: [boost] Common future base class (was Re: Boost.Fiber mini-review September 4-13)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-09-06 10:52:36

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<tuple<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