--------------------------- Vicente Juan Botet Escriba ----- Original Message ----- From: "Johan Torp" <johan.torp@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, May 13, 2008 11:42 AM Subject: Re: [boost] Re view Request: future library : what does future of references exactly means?
vicente.botet wrote:
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);
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();
Secondly, you can't prohibit the calling thread to access it's original reference. So the problem isn't really solved.
You are right, the problem is not solved.
Presently, I haven't seen any use cases which would motivate reference support for futures. Not allowing references is a safety net in it's own right.
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(); 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. Vicente