On Fri, 16 Mar 2007 09:30:24 -0400, Frank Mori Hess wrote:
On Thursday 15 March 2007 23:30 pm, Braddock Gaskill wrote:
There is no future "proxying" or "chaining" of futures, per se, instead all future references point to the same implementation object under the hood, but do abstract the actual retrieval of the value. The effect is largely the same.
Is this an implementation detail, or does it change the semantics?
Implementation detail. Eliminates the method forwarding and signal/callback connection/disconnection, and eliminates proxy mutexes. Looking at your implementation laid the groundwork though, and I'd appreciate if you could put some eyeballs on what I did. The split promise/future concept eliminates the nasty setValue() error case, as I think you pointed out in an earlier post.
example, if I the class A is convertible to B and B is convertible to C, but A is not directly convertible to C, can I get a future<C> from a future<A> by going through a future<B> as an intermediary?
This should work. It will chain through a couple of my detail::return_value_type_adaptor instances. See test_future.cpp. Not exactly the case, but implementation-wise it is doing the same. void TestCase9() { // assignable, but different, types boost::promise<int> p; boost::future<long> lfut(p); boost::future<int> ifut(p); boost::future<unsigned int> uifut = lfut; boost::future<unsigned char> ucfut(uifut); p.set(27); BOOST_CHECK_EQUAL(lfut.get(), 27); BOOST_CHECK_EQUAL(ucfut.get(), 27U); } One thing I did not do (yet) was add a generic conversion function capability. This is easily done now (in fact I did a rough cut and then removed it). I was hoping to get at least one real-life example usage of how it is used - say exactly how the syntax of a future<vector<T> > to future<T> conversion might work, as you had mentioned? There seems to be a fine line between embedded conversion and creating a more explicit function future<T> element_extractor(future<vector<T> > f, int index); Braddock Gaskill Dockside Vision Inc