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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-05-13 02:51:01

"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.

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

Anthony
-- 
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL