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

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

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

On Wednesday 14 March 2007 15:26 pm, Braddock Gaskill wrote:
> On Wed, 14 Mar 2007 14:09:37 -0400, Frank Mori Hess wrote:

> > then you should be able to do (without blocking)
> > promise<A> p;
> > future<A> fa(p);
> > future<B> fb = fa;
>
> Does libpoet already do this?  Any advice on implementation?  I split my
> future_impl from the actual value type so that I could more easily
> support this, but haven't worked out the details yet.

Yes.  I have a future_body and a future_body_proxy class, both derived from 
future_body_base.  A future_body handles the simple case of a future 
waiting on a value.  A future_body_proxy observes another future_body_base 
and becomes ready when the future_body_base it is observing becomes ready.  
It then sets its value by applying a conversion function to the value from 
the other future_body_base.  This handles implicit conversions, and 
conversions done with a user-specified conversion function.  See the 
poet/future.hpp file:

http://www.comedi.org/cgi-bin/viewcvs.cgi/libpoet/poet/future.hpp

> > -Constructing a future from another with an incompatible template type
> > via a user-supplied conversion function.  Useful for extracting future
> > elements from future containers, for example.
>
> I think I saw you mention this in another post, and hoped you would come
> back with it.  Can you give me a short example of how this syntax would
> work that I can work towards?

I just have a constructor that takes an additional argument for the 
conversion function.  The conversion function argument is really a 
boost::function<T (const U&)> .  See

http://www.comedi.org/projects/libpoet/classpoet_1_1future.html#a3

> > -Adding a promise::fulfill() that accepts a future with a compatible
> > template type.  The effect would be that promise::fulfill() would be
> > called with the value from the future when it is ready.
>
> So this effectively chains the future's?  Ie:
> promise<T> p1;
> future<T> f1(p1);
> promise<U> p2;
> future<U> f2(p2);
> p2.fulfill(f1);
> f2.wait(); //actually waits for f1 to complete.

I think of it as chaining the promises, but yes you're understanding me 
correctly.

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFF+Fqm5vihyNWuA4URAkIvAJ4pAJHA8YU+HTwoNelKFN7j31amrgCfai1j
ifWPvF7GrBL8peAwCycpNGQ=
=jwST
-----END PGP SIGNATURE-----