Boost logo

Boost :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-06-02 12:34:31


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 02 June 2008 11:45 am, Frank Mori Hess wrote:
> My use case requires future_value. Furthermore, from my experience
> implementing the future_value features in poet::future, I doubt it will be
> possible to implement future_value relying only the public interface of
> future_handle.

Actually, let me back down from that a little. I think if the futures library
provided a future_combining_barrier (which I was grouping with the
future_value functionality in my head before), I could implement a
future_value on top of a future_handle.

To elaborate, the future_combining_barrier would let you produce a
future_handle<R> from a heterogeneous group of input future_handle objects,
plus a user-supplied combiner function. The combiner is called to produce
the value for the future_handle<R> from the values of the input
future_handles when they are ready.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIRCEY5vihyNWuA4URAnTGAKCVERqhgxyCistma9Tl9en01h3SYgCgkgX4
1gqqfSTzFnUK8/l6XFy8Dik=
=UZG0
-----END PGP SIGNATURE-----


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk