Boost logo

Boost :

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

Vicente Juan Botet Escriba
----- Original Message -----
From: "Johan Torp" <johan.torp_at_[hidden]>
To: <boost_at_[hidden]>
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.


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