-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've just noticed that neither Anthony's or Braddock's future libraries seem to support construction of a future directly from a value, like future<int> fut_int(5); Adding such a constructor gives support for implicit conversion of a value of type T to a future<T>. So a function which takes futures as arguments can also seamlessly accept values: future<void> my_func(future<int> f1, future<int> f2); my_func(fut_int, 3); This is important for the usability of poet::active_function, which takes all parameters as futures. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILDds5vihyNWuA4URAguzAJwIFdVharrD6w1QMq0R7H6NVV8TJgCfQ1hw MeYEoiqA5mOy0wY52n/tHE0= =6tTp -----END PGP SIGNATURE-----
----- Original Message ----- From: "Frank Mori Hess" <frank.hess@nist.gov> To: <boost@lists.boost.org> Sent: Thursday, May 15, 2008 3:15 PM Subject: [boost] [future] direct construct from value
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've just noticed that neither Anthony's or Braddock's future libraries seem to support construction of a future directly from a value, like
future<int> fut_int(5);
Adding such a constructor gives support for implicit conversion of a value of type T to a future<T>. So a function which takes futures as arguments can also seamlessly accept values:
future<void> my_func(future<int> f1, future<int> f2);
my_func(fut_int, 3);
This is important for the usability of poet::active_function, which takes all parameters as futures.
Hello, you can do promise<int> p; future<int> f(p); p.set_value(3); my_func(fut_int, f); which is much more cumberscome. Where do you store the associated promise? Maybe you need a wrapper of a promise and a future that behaves like that that is convertible to a future. template <typename T> struct promise_future { promise_future(T& v) : p_(), f_(p_) { f_.set_value(v); } operator future<T>() { return f_;} promise<T> p_; future<T> f_; } The problem is that yoy have two user conversions, so you will need either promise_future<int> pf(3); my_func(fut_int, pf); or my_func(fut_int, promise_future<int>(3)); Does this works for you? Best Vicente
Frank Mori Hess wrote:
I've just noticed that neither Anthony's or Braddock's future libraries seem to support construction of a future directly from a value, like
future<int> fut_int(5);
Adding such a constructor gives support for implicit conversion of a value of type T to a future<T>. So a function which takes futures as arguments can also seamlessly accept values:
future<void> my_func(future<int> f1, future<int> f2);
my_func(fut_int, 3);
Adding an explicit constructor is one thing. Allowing implicit type conversions is more dangeous and needs to be thought through carefully. Could you make do with explicit constructing? my_func(fut_int, future<int>(3)); Johan -- View this message in context: http://www.nabble.com/-future--direct-construct-from-value-tp17253307p172706... Sent from the Boost - Dev mailing list archive at Nabble.com.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 16 May 2008 05:14 am, Johan Torp wrote:
Frank Mori Hess wrote:
I've just noticed that neither Anthony's or Braddock's future libraries seem to support construction of a future directly from a value, like
future<int> fut_int(5);
Adding such a constructor gives support for implicit conversion of a value of type T to a future<T>. So a function which takes futures as arguments can also seamlessly accept values:
future<void> my_func(future<int> f1, future<int> f2);
my_func(fut_int, 3);
Adding an explicit constructor is one thing. Allowing implicit type conversions is more dangeous and needs to be thought through carefully. Could you make do with explicit constructing?
my_func(fut_int, future<int>(3));
Can you come up with any specific examples of how implicitly constructing a ready future from a value would be dangerous? It's not like implicity constructing a shared_ptr from a raw pointer, which might cause the raw pointer to be accidentally deleted. It's certainly less dangerous than going the other direction (which has generated some controversy): implicit conversion of a future to a value, which can block. Note, I'm not suggesting adding support for direct assignment from the template type. I certainly wouldn't make the poet::future constructor explicit and diminish useability without a concrete reason for doing so. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILZZ15vihyNWuA4URAnJIAJoDjRHtgNAAQ4Bm15AislS4kzg1tgCdG2pg DG/tpcYd4QldDsViLlL9/hw= =jdVL -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
Can you come up with any specific examples of how implicitly constructing a ready future from a value would be dangerous? It's not like implicity constructing a shared_ptr from a raw pointer, which might cause the raw pointer to be accidentally deleted.
I haven't thought of any examples. I was just wondering how much you rely on in it and how useful it is. Frank Mori Hess wrote:
It's certainly less dangerous than going the other direction (which has generated some controversy): implicit conversion of a future to a value, which can block.
Agreed. Johan -- View this message in context: http://www.nabble.com/-future--direct-construct-from-value-tp17253307p172796... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (3)
-
Frank Mori Hess -
Johan Torp -
vicente.botet