Re: [boost] [futures] boost::futures - convertible types

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-03-16 11:05:54

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