From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-28 08:48:52
-----BEGIN PGP SIGNED MESSAGE-----
On Wednesday 28 May 2008 05:55 am, Johan Torp wrote:
> Do you propose to remove reference counting from futures and use
> shared_ptr<future<..>> instead?
No, the mentions I made of shared_ptr were not important. I was only trying
to convey that promise::has_future could be easily implemented by imagining a
typical implementation of promise/future where they both are implemented by
having a shared_ptr to some common object.
> I believe the main motivation for a unique_future was to be able to move
> large/expensive types in the get-function instead of copying them.
> shared_future<R> requires it's client to copy the data to move it into
> their own data structures. It has the following signature:
> R const & get() const;
> unique_future<R> moves the value out of the future and is "consumed" once
> get() has been called. It has the following signature:
> R&& get();
> I don't like having both shared_future and unique_future either. One could
> perhaps distinguish between move-get and const_ref-get somehow and only
> allow the former if use_count == 1. One problem is that the promise
> typically belongs to some other thread and new futures can be created
> concurrently after having queried use_count. Another option is declaring
> whether the future is unique or shared as a parameter in the futures
> constuctor. An exception could be thrown if you try to create more futures
> from a uniquely "owned" promise.
> Not distuinguishing between unique and shared might remove some type safety
> and clarity in user code. Some of the N2627 future proposal authors can
> probably provide more insight.
This seems unrelated to what I was trying to get at with promise::has_future.
The idea is a promise-fulfilling thread can query promise::has_future if it
likes, and choose to exit early if there are no futures out there that might
be interested in its result value. Or, if the promise-fulfilling thread is
intended to cause some side-effects independent of setting futures, it can
proceed and ignore promise::has_future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk