Re: [boost] Review Request: future library : what does future ofreferences exactly means?

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-13 13:24:45

----- Original Message ----- 
From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, May 13, 2008 8:51 AM
Subject: Re: [boost] Review Request: future library : what does future 
ofreferences exactly means?

> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>
>> Imagine now we had a function which returs a value and had an out 
>> parameter
>> (maybe by reference)
>>
>> Result f(InOut& ref);
>>
>> Now we want to refactor this function (either because the new 
>> implementation
>> will introduce an IO wait, or because the old blocking  implementation 
>> could
>> not be supported. Which should be the interface of the new function. The
>> first thing could be to try with
>>
>>     future<Result> f(InOut& ref);
>>
>> but nothing forbids the caller to use the ref parameter before the 
>> operation
>> has completed and which could be invalid. If we want consistency what we
>> would need is something like
>>
>>     future<Result> f(future<InOut&>& ref);
>>
>> IMO this do not works in any proposal?
>
> You can write it with my proposal, but I'm not sure it means what you 
> intend,
> given what you write below.
>
>> Do we need future to works with in/out references?
>>
>> Yet another example
>>     future<Out&> f();
>>
>> Note that future<Out&> and future<InOut&> should not mean the same. Do we
>> need two future of reference classes? future<InOut&> will need a 
>> constructor
>>     future<InOut&>(InOut&),
>> but the assocaited promise should copy the value when doint the 
>> set_value.
>
> If the promise associated with your future<InOut&> should copy the value, 
> then
> what you want is a future<InOut>. If you had a future<InOut&>(InOut&)
> constructor, then you could /still/ use the original InOut& before the 
> future
> had returned, just as if you passed a plain reference to the function.
>
> With my (updated) proposal, unique_future<T>::get() returns an
> rvalue-reference, so you could move/copy this into the InOut value you 
> intend
> to use, or you could use shared_future<T>, where get() returns a const
> reference.

Well let me come back to my initial example. Supose that I had
    Result f(InOut& ref);
    // ...
        {
            InOut v=0;
            // ...
            v = 13;
            Result r = f(v);
            // ...     use r or v;
            g(r, v);
            v = 15;
        }

Do you mean that the following works with your proposal?

    unique_future<Result> f(shared_future<InOut>& ref);
    // ...
        {
            shared_future<InOut> v; v->get()=0;
            // ...
            v->get() = 13;
            unique_future<Result> r = f(v);
            // ... use r or v;
            g(r->get(), v->get());
            v->get() = 15;
        }

>> Anthony, sorry for short cut (futures instead of unique_future or
>> shared_future). In order to be coherent with the thread library
>> (mutex/shared_mutex), should't unique_future be named future?
>
> unique_future/shared_future is by analogy to unique_ptr/shared_ptr, which 
> I
> think is a closer match than mutex/shared_mutex.

OK. I understand

Vicente