Boost logo

Boost :

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

> 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 Williams            | Just Software Solutions Ltd
Custom Software Development |
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Boost list run by bdawes at, gregod at, cpdaniel at, john at