From: Edd Dawson (lists_at_[hidden])
Date: 2008-08-30 05:45:59
On 30 Aug 2008, at 01:23, Bram Neijt wrote:
> Dear reader,
> I've been wanting to implement a future in C++ for some time, and
> combined some code to come up with the attached. The idea is that the
> future is a function wrapper around a function call which will call
> function in a second thread upon creation. Then at a later moment, the
> future can yield the return value of the wrapped function (or block
> until this result is know).
> I'm happy with the result I got so far. It's a very rough draft, and I
> would like your help to clean up some details:
> - I would like to have the Future wrapper work with the
> int (argument, argument)> syntax, but I can't figure out how to get
> return type from that syntax to allow for the return value to be
> (the d_result member).
Is this really necessary? Once you have a future, you only care about
its result, surely?
> - What would be the best way to handle function arguments? Binding all
> the parameters before passing the resulting bound function object
> like the solution, but is it really the best solution?
I think so; by the time the underlying functor is called in the other
thread, the arguments may have disappeared, making it too late to do a
Here's my attempt:
I found that with my mechanism at least, bind had to create a very
large number of copies, so I actually ended up making a
shared_ptr<tuple> containing copies of all the arguments and passing
that to the thread that makes the eventual call.
This way the arguments were only copied once, but the shared_ptr
multiple times, which isn't a big deal.
> And last but not least: has this already been done and what is the
> general opinion within the boost community on having a class like
I have seen many others floating around, too. I'm sure others will
chip-in in due course with more info.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk