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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk