-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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); // ... - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF+GBe5vihyNWuA4URAgpyAJ9yDcnWgZtV8nkke4uKDsMUZDx/CACdEswq rDoy7kzchQgP1CxfEP4OG/4= =ElUK -----END PGP SIGNATURE-----