-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 02 June 2008 15:42 pm, Peter Dimov wrote:
Oh, I came up with a reason that having future_value objects as inputs can be preferable to the solution you describe. Your solution forces the "lifted" functions to always take templates arguments. But template methods can't be made virtual. Also, you can't pass them to bind() without manually specifying all the template parameters.
Hm. I'm not sure I follow. Let's say that I have:
struct A { virtual int f( long x ) = 0; };
int g();
future<int> h( A* pa ) { return async( &A::f, pa, async( g ) ); }
What's the problem with the outer async recognizing that its third argument is a future and treating it as a dependency?
That's interesting, is this async stuff from an existing library somewhere, or is it a hypothetical interface? I don't see any problem with it. I was thinking of a virtual active object class, like: struct ActiveA { virtual future_value<int> f( future_value<long> x ) = 0; }; I believe your solution could be used to achieve similar effects, but it is a very different interface. I'm not saying my interface is the only way to skin the cat, just that I want to be able to implement the interface I prefer and make it work as well as possible. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIRFsx5vihyNWuA4URAtQ0AKDK/MKpUzFJuAUk/yUhxxUkuny3MQCfdBNu KYeis+VWtWRuNzABJcqrbx8= =NJKJ -----END PGP SIGNATURE-----