The Boost.FSM library is an implementation of FSM (stands for Finite State Machine) programming concept. The main goals of the library are:

• Simplicity. It should be very simple to create state machines using this library.
• Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases.
• Extensibility. A developer may want to add more states to an existing state machine. A developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code.

A number of additions and modifications to the Property Map Library, including:

• A constant-valued property map, useful for naturally unweighted graphs.
• A noop-writing property map, useful when you have to provide an argument, but just don't care about the output.
• See ChangeLog for details.

A number of additions and modifications to the Graph Library, including:

• Two new graph classes (undirected and directed) which are intended to make the library more approachable for new developers
• A suite of graph measures including degree and closeness centrality, mean geodesic distance, eccentricity, and clustering coefficients.
• An algorithm for visiting all cycles in a directed graph (Tiernan's from 1970ish). It works for undirected graphs too, but reports cycles twice (one for each direction).
• An algorithm for visiting all the cliques a graph (Bron&Kerbosch). Works for both directed and undirected.
• Derived graph measures radius and diameter (from eccentricity) and girth and circumference (from Tiernan), and clique number (from Bron&Kerbosch).
• An exterior_property class that helps hides some of the weirdness with exterior properties.
• run-time and compile-time tests for the new algorithms.
• a substantial amount of documentation
• Graph cores, implemented by David Gleich (@Stanford University)
• Deterministic graph generators - capable of creating or inducing specific types of graphs over a vertex set (e.g., star graph, wheel graph, prism graph, etc). There are several other specific types that could be added to this, but I haven't had the time just yet.

This paper proposes a kind of return buffer that takes a value (or an exception) in one (sub-)thread and provides the value in another (controlling) thread. This buffer provides essentially two interfaces:

• an interface to assign a value as class promise and
• an interface to wait for, query and retrieve the value (or exception) from the buffer as classes unique_future and shared_future. While a unique_future provides move semantics where the value (or exception) can be retrieved only once, the shared_future provides copy semantics where the value can be retrieved arbitrarily often.

A typical procedure for working with promises and futures looks like:

• control thread creates a promise,
• control thread gets associated future from promise,
• control thread starts sub-thread,
• sub-thread calls actual function and assigns the return value to the promise,
• control thread waits for future to become ready,
• control thread retrieves value from future.

Also proposed is a packaged_task that wraps one callable object and provides another one that can be started in its own thread and assigns the return value (or exception) to a return buffer that can be accessed through one of the future classes.

With a packaged_task a typical procedure looks like:

• control thread creates a packaged_task with a callable object,
• control thread gets associated future from packaged_task,
• control thread starts sub-thread, which invokes the packaged_task,
• packaged_task calls the callable function and assigns the return value,
• control thread waits for future to become ready,
• control thread retrieves value from future.