Re: [boost] [futures] untyped_promise or future<void>

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-03-24 11:49:23

On Saturday 24 March 2007 09:20 am, Braddock Gaskill wrote:
> I've come across a few cases where I need access to some of the
> promise and future members (ready(), cancel(), etc), but don't actually
> care about the type of the promise/future.  For example, I have a
> scheduler, and I want to be able to call
>
> scheduler.post(f /* function */, p /* promise */)
>
> where my scheduler can then add a cancelation handler to the promise,
> possibly track if the future/promise has been fulfilled, cancel the
> promise, etc, but yet has no need to know the type of the promise (which
> would require a templated post() function).
>
> I solved this problem by creating an "untyped_promise" class, which is
> constructable from a typed promise<T>, but gives access to all methods
> of the same promise instance, except for set() and get() obviously.
>
> I was interested in thoughts on this untyped_promise.
>
> Looking around, I found a post by Herb Sutter to the cpp-threads list
> where he also considered this situation.  He suggested making future<T>
> implicitly convertible to future<void> so that future<void> could be
> used for this purpose (not using a split future/promise concept).  I
> kinda like that idea actually.  Thoughts?

Seems like a good idea to me.  I didn't like it at first because I thought 
you were suggesting giving a new alternate meaning to future<void>, and 
getting its behavior confused with a smart pointer class, but really it 
doesn't seem to.

I don't really see the point of bringing promise into this though.  Is it 
just because your add_callback is a member of promise and not future 
(that's only my recollection)?  In libpoet, slots can be connected to 
futures to observe a promise being fulfilled or reneged, and there is a 
future::cancel().  I seem to remember your future having a cancel too.  I 
didn't even bother to make promises implicitly convertible between 
compatible template types as it all seems to be covered by implicitly 
convertible futures.

-- 
Frank