On Fri, 16 Mar 2007 12:11:38 -0400, Frank Mori Hess wrote:
On Friday 16 March 2007 11:05 am, Braddock Gaskill wrote:
One thing I did not do (yet) was add a generic conversion function
Here's an example extracting at(1) from a future vector:
poet::future<std::vector<double> > myVec; poet::future<double> myVecElement(myVec, boost::bind<const double&>(&std::vector<double>::at, _1, 1));
Hrm, this has profound implications. I don't know if they are good or bad, but they go beyond my current understanding of the future idiom. This allows you to not just embed conversion functions, but ANY function, in the guise of a future<T>. future<double> func1(const future<double> &a); future<double> func2(const future<double> &a); future<double> func3(const future<double> &a); promise<double> p; future<double> f0(p); future<double> f1(f0, func1); // f1.get() equiv to func1(f0) future<double> f2(f1, func2); // f2.get() equiv to func2(func1(f0)) f2.get(); // Does caller realize this is actually a call to func2(func1(f0))?? future<double> f3 = std::fork(bind(&func3, f2)); // Did the author of func3() realize his call to a.get() might do _anything_? Of course the assignable type conversions already let the cat out of the bag, not just the generic conversion functions. In fact, my add_callback() hook opens a similar bag of worms for the promise::set() call. I really only want add_callback as a hook to allow independent event notification models and composition to be developed on top, not for end user use. So, good, bad, or awesome? ;)