[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 
just unique_future.

- 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 mailing list