Re: [boost] [futures] boost::futures

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2007-03-14 16:38:35

Frank Mori Hess wrote:

> > > Future<bool> operator||(const Future<T> &a, const Future<U> &b);
> >
> > 1. Why do you would do that? Do you have a use case?
> 
> Making active functions that take futures as arguments and 
> return futures as return values is the primary feature of 
> libpoet.  See 
> 
> http://www.comedi.org/projects/libpoet/
> 
> So the operator|| above would be used if you wanted to || two 
> results and pass the result of the || to another active 
> function without blocking waiting for the futures to become 
> ready.  Really it was just an example though, I'm not 
> currently planning to implement this (although maybe I will 
> someday if I discover it to be useful).

Passing the result of f1 || f2 does not block execution at all. F1 || f2
yields just another future you will have to dereference first to make it
returning it's value (or blocking, if the value is not available).

So I'ld rather cross the bridge, when I'm there. Relying on fictional use
cases is at least questionable.

> > 2. If you really have to do that, simply do not include the 
> header(s) 
> > defining the operators.
> 
> I don't really have to define an operator||, I could just 
> give the function an ordinary name.  My point is, composing 
> futures like in Thorsten Schütt's implementation doesn't 
> really have to define an operator|| either.  And, if I had to 
> choose which function had a more legitimate claim to use 
> operator||, I'd choose my example.
> 
> Not including the headers isn't really a solution, since it 
> precludes the use of the conflicting functions in the same code.

This doesn't preclude anything. You said you don't _want_ to use the
overloaded semantics of futures at all (because you don't like them). How
this may then conflict with other code? I hold my point: just don't include
the header containing the questionable operators and you don't have to pay
for them.

> Pointless overloading isn't a good thing.   What does it buy 
> you here?  A 
> pair of parenthesis.

Syntactic sugar improves expressiveness, which makes code more readable. But
as always this is a matter of style and personal preference. I don't want to
start a religious discussion here. Just don't use the syntactic sugar, if
you don't like it.

The usage of operator overloading has one advantage over a similar solution
using functions, though. When combining futures you ultimately want to
flatten the composed return types: i.e. for a f1 || f2 || f3 (with different
return types T1, T2 and T3) you want to get a variant<T1, T2, T3> as the
composite return type and not a variant<variant<T1, T2>, T3> (as you would
get using simple functions taking two parameters).

This naturally involves some meta template magic to construct the required
return types. Using functions you'll have to do this by hand, using
operators you can reuse existing meta-template frameworks like proto
allowing to implement this with minimal effort.

Regards Hartmut