Boost logo

Threads-Devel :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-03-12 10:30:55


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

On Tuesday 11 March 2008 17:14 pm, Anthony Williams wrote:
> Quoting Frank Mori Hess <frank.hess_at_[hidden]>:
> > Also, have you considered supporting implicit conversions between
> > future<U> and future<V> where there is an implict conversion between U
> > and V? My libpoet library does that, and it's helpful for passing
> > futures between active object functors that return futures and accept
> > them as arguments.
>
> I haven't considered that. It seems awkward to me, as you could start
> with a future<U>, convert to future<V>, then to future<W>, then to
> future<X>, then to future<Y>. In each case there would be an implicit
> conversion, but you wouldn't normally be able to convert a U to a Y
> (too many UDCs).

I'm not sure what you mean by "too many UDCs"?

> For this to work, therefore, you'd have to wrap the
> internal data with every conversion, otherwise some future<V>s could
> be converted to future<W>s, but not others. How did you handle this
> case?

I'm not sure which case you're thinking of when you say some futures could be
converted but not others? Wrapping the internal data with every conversion
sounds roughly like what I did. I tried to make the conversions for futures
behave just like the values they are wrapping. So in the example you give,
the value for the future<Y> will be created by going through all the
conversions U to V to W to X to Y. U does not have to be directly
convertible to Y.

The internals of my promise/future uses a base class "future_body_base" with
two derived types. One is "future_body" for a normal promise/future, and the
other derived type is "future_body_proxy" which observes a "future_body_base"
and constructs a value (which is a different type) from the value of the
observed "future_body_base" when it's ready.

I believe Braddock Gaskill implemented similar functionality in his futures
library, but with a different implementation.

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

iD8DBQFH1+kg5vihyNWuA4URAmyhAKCGfDJ0VofyaBjbF4UBFPXojjjp2wCgvZrO
FpOnhIgJSJFINC7+Nj6MNLA=
=yyRH
-----END PGP SIGNATURE-----


Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk