vicente.botet wrote:
If we want consistency what we would need is something like
future<Result> f(future<InOut&>& ref);
Firstly, this is a dangerous design. The calling thread must keep the reference alive until the future is ready - no matter what. For instance, what if it's owner thread tells it to terminate?
What do you propose instead? What do you think of future<Result> f(cosnt InOut& in, future<InOut>& out);
future<InOut> fv; r= f(v, fv) v = fv.get();
If result was binary - succeed or "not possible" I would use unique_future<boost::optional<InOut> > f(); otherwise unique_future<tuple<Result, InOut> > f(); or unique_future<variant<ErrorCode, InOut> > I'm assuming InOut is movable and we have r-value references. Otherwise, use unique_ptr/auto_ptr instead of InOut. If we need shared_futures I would use shared_ptr instead of InOut. vicente.botet wrote:
Yet another example future<Out&> f();
This is also very dangerous, the promise-fulfilling thread must guarantee that the reference is valid until program termination as it can't detect when the future dies. Even if it could detect future destruction, it would be a strange design. Shared_ptrs or some kind of moving should be applied here.
This is not more dangerous that Out& f();
Sharing references between threads is always very dangerous and should be avoided. The owning thread can typically not know when the other thread will access it and must hence keep it alive until the program terminates and can never alter the data again (unless it's a concurrent object). vicente.botet wrote:
We know how dangerous it is and we use every time. This reference point usualy to a member object, and the object can be deleted.
The single threaded case is a lot less dangerous. As a side note, I think return-by-reference is an almost deprecated programming style. Code which depend on boost can use auto_ptr, shared_ptr, variant, optional and tuples to easily return data, unless performance is _really_ critical. R-value references will remove the expensive copying for movable types too. Those are my thoughts on the matter. Johan -- View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29... Sent from the Boost - Dev mailing list archive at Nabble.com.