Re: [boost] [futures] boost::futures

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-03-14 15:26:11

On Wed, 14 Mar 2007 14:09:37 -0400, Frank Mori Hess wrote:
> I'd prefer a signal/slot to add_callback().  That is: thread_safe_signals 
> and moving to Boost.Signals when a thread-safe version is accepted. 

I would prefer a signal too, although I wanted to minimize the boost-isms in
the interface in the hope that it will be closer to whatever future concept
gets into C++0x (if any).  I'd probably expose a thread_safe_signal once
available.

> then you should be able to do (without blocking)
> promise<A> p;
> future<A> fa(p);
> future<B> fb = fa;

Does libpoet already do this?  Any advice on implementation?  I split my
future_impl from the actual value type so that I could more easily support
this, but haven't worked out the details yet.

> Another suggestion is to rename promise::set() (boring) to 
> promise::fulfill() (makes me smile).  And if there is an opportunity to 
> work the name "empty_promise" in as a class or a concept, that would be 
> clever too.

Personally, I love your fulfill() name.  I would also prefer fail() to
set_exception()...it seems more descriptive since it is more than just an
accessor method.  I didn't want to stray TOO far from Peter's C++ language
proposal though.

If I add a default constructor to future<T>, I'll be sure to have it throw
empty_promise or empty_future if get() is called before it is initialized. 
;)

> -Constructing a future from another with an incompatible template type via 
> a user-supplied conversion function.  Useful for extracting future 
> elements from future containers, for example.

I think I saw you mention this in another post, and hoped you would come back
with it.  Can you give me a short example of how this syntax would work that I
can work towards?
 
> -Adding a promise::fulfill() that accepts a future with a compatible 
> template type.  The effect would be that promise::fulfill() would be 
> called with the value from the future when it is ready.

So this effectively chains the future's?  Ie:
promise<T> p1;
future<T> f1(p1);
promise<U> p2; 
future<U> f2(p2);
p2.fulfill(f1);
f2.wait(); //actually waits for f1 to complete.