From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-03-14 16:51:41
-----BEGIN PGP SIGNED MESSAGE-----
On Wednesday 14 March 2007 16:38 pm, Hartmut Kaiser wrote:
> Frank Mori Hess wrote:
> > 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).
I thought you asked me why I'd want to use the operator|| that I suggested,
so I gave an example of its use. You seem to be talking about the other
operator|| that I didn't like.
> > 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.
Ah, I was thinking the operator||, etc was the only way provided to compose
the futures. If they are also available via normal function names, then I
retract my complaint.
> 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.
Why couldn't you just overload the function to take varying numbers of
arguments? I'll just use the name "compose_variant" for illustration:
variant<T1, T2> compose_variant(T1 t1, T2 t2);
variant<T1, T2, T3> compose_variant(T1 t1, T2 t2, T3 t3);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
-----END PGP SIGNATURE-----