Re: [boost] Updated version of futures library

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-31 05:20:43

Hartmut Kaiser wrote:
> 
>> Yes. I was trying to stay away from the overloaded operators, but this
>> is certainly the same issue.
> 
> Are you interested in something like this? 
> What's your reason for 'staying away' from the operators so far?
> 

There has been some confusion as to what the operator semantics should be.
Instead of returning the first ready future, one could return a future
holding the value of lhs.get() && rhs.get() as soon as this is computable.

I.e.  future<bool> operator&&(future<bool>& lhs, future<bool>& rhs) would
return a new future which is equal to true, iff lhs.get()==true and
rhs.get()==true. If either one returned false it would be false and
otherwise the composed future would not be ready yet.

I think this is more natural semantics, but most people seem to think
otherwise. Because of this confusion, I think we should leave the operators
be. I believe this is what Anthony is referring to.

Note that if we let the operators map against the templated types operators
as soon as they are computable, we could implement arithmetic operators too: 
future<double> a,b,c;
future<double> d = a*(b+c*a); // Will become ready when a, b and c is ready
This would allow "lifting" of aribitrary arithmetic expressions to futures.

Johan
-- 
View this message in context: http://www.nabble.com/Updated-version-of-futures-library-tp17555389p17573449.html
Sent from the Boost - Dev mailing list archive at Nabble.com.