[hpx-users] Breaking change: future
Agustín K-ballo Bergé
kaballo86 at hotmail.com
Wed Jan 8 17:39:26 CST 2014
In order to align HPX to the C++ standard, hpx::future is being
deprecated. The standard provides two kinds of future: one for unique
ownership (std::future) and one for shared ownership
(std::shared_future), much like the unique and shared pointers. HPX
previously tried to provide both behaviors with a single future having
both a get() and move() operation.
The first step in the migration process was the implementation and
adoption of the standard futures, named hpx::unique_future and
hpx::shared_future. All HPX functions previously returning hpx::future
return now hpx::unique_future, from which a hpx::future/shared_future
can be initialized. The following steps will be the complete removal of
the deprecated future, and the renaming of unique_future to future.
The now deprecated hpx::future is no longer used internally by HPX, but
it is still supported if the HPX_ENABLE_DEPRECATED_FUTURE flag is on.
Otherwise, if your compiler supports template aliases, the
HPX_UNIQUE_FUTURE_ALIAS flag can be set to define future<R> as an alias
to unique_future<R>, in order to start using the definitive names now.
A few things to keep in mind while updating your code:
- unique_future is, as its name implies, movable-only. There can only be
at most one instance owning the represented return value. It cannot be
used in context that require copy-constructibility, use f.share()
instead to turn it into a shared_future.
- When the return value is consumed the future gets invalidated. If you
need to use the return value of a unique_future more than once, give it
a name instead of using multiple .get()s. Other uses that consume the
future are .then() and when_*().
- Sometimes there's a need to bind unique_futures to a call expression
that will only be called once --particularly when attaching
continuations with .then()--. In those cases, it is possible to use
HPX's implementation of bind together with one_shot instead of turning
the future into a shared one. This works for all movable-only types, not
- While shared_future is closer in semantics to the deprecated future,
most futures are naturally unique (as they represent return values).
Within all HPX core, tests and examples, there's only a handfull of
shared_futures; from those, only a couple are true shared_futures, the
rest of them are artificial cases (in tests) or poor design decisions.
Agustín K-ballo Bergé.-
More information about the hpx-users