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
> 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
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:
f2.wait(); //actually waits for f1 to complete.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk