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

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-03-14 16:51:41

-----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-----