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