Async++ is a C++11 framework inspired by Microsoft's PPL

The design comes from PPL and a standards proposal

Async++ is described as a lightweight concurrency framework for C++11, and the README is clear about its ancestry: the concept was inspired by the Microsoft PPL library and the N3428 C++ standard proposal.

The project identifies both the Microsoft PPL library and N3428 as inspirations for its design.

Which puts its position awkwardly. In 2026, a project targeting C++11 with a future and task model is competing with the implementation of that same model inside every modern standard library. The difference is not capability so much as surface: Async++ offers `spawn` returning a task you can compose, `then` for continuation, `when_all` for joining, and a set of parallel algorithms over ranges, which reads more like a small library than like the standard headers.

There is also a scope statement worth noting. The library is deliberately small. The repository top level includes `include/`, `src/`, `examples/`, `CMakeLists.txt` and a CMake config template. There is no scheduler pool of its own beyond what the documentation describes, and no build system beyond CMake.

The header is included as `<async++.h>`, and the example program includes it alongside `<iostream>` and nothing else.

spawn, then and when_all build a task chain

The example in the README is the best documentation in the project, because it shows five tasks and then three parallel algorithms in one file.

#include <iostream>
#include <async++.h>

int main()
{
    auto task1 = async::spawn([] {
        std::cout << "Task 1 executes asynchronously" << std::endl;
    });
    auto task2 = async::spawn([]() -> int {
        std::cout << "Task 2 executes in parallel with task 1" << std::endl;
        return 42;
    });

`async::spawn` takes a callable and returns a task. In the example one task returns void and the other returns an int, so the task type carries the return value and the continuation can take it.

`task2.then(...)` takes a callable receiving the previous result and returns a new task, which is where the composition is. The continuation in the example multiplies the value by three, so task three's result is the value task two returned, transformed.

`async::when_all(task1, task3)` joins a set of tasks, and the resulting task's continuation receives a tuple. The example then pulls the second element out of that tuple with `std::get<1>(results).get()`, which tells you the joined results are the task objects themselves and that `.get()` on a task blocks for its value.

So the chain is: spawn for the leaves, then for each dependency, when_all for joins, and `.get()` to block at the end. Five tasks, and the output block in the README lists what prints and in what order, noting the order may vary in some places.

That is the whole model, and the wiki says to read the Tasks page first and strongly recommends doing so.

Parallel algorithms cover the three cases you actually write

After the task chain, the same example runs three parallel algorithms, which together cover most of what a C++ developer reaches for a concurrency framework to do.

`async::parallel_invoke` takes two or more callables and runs them in parallel. The example prints two lines from two lambdas, and the two halves of the output may interleave.

`async::parallel_for` takes a range and a body. The range is built with `async::irange(0, 5)`, an integer range helper, so the framework supplies the range types rather than requiring you to write iterators:

async::parallel_for(async::irange(0, 5), [](int x) {
    std::cout << x;
});
std::cout << std::endl;

int r = async::parallel_reduce({1, 2, 3, 4}, 0, [](int x, int y) {
    return x + y;
});
std::cout << "The sum of {1, 2, 3, 4} is " << r << std::endl;

`parallel_reduce` takes a container, an initial value and a binary operation. In the example that is an initializer list of four integers, zero, and addition, producing the sum.

That is the design: three functions, no user-visible thread pool, no executor to configure. The scheduler page in the wiki is described as the low-level details and how to customise it, which means the default scheduling is meant to be good enough and the escape hatch exists rather than being the starting point.

The API reference page covers the rest of the classes and functions, so the visible README is deliberately the shape rather than the catalogue.

The platform list is a workaround in one row

The supported platforms section states that the only requirement is a C++11 compiler and standard library, then immediately notes C++11 is not fully implemented on most platforms, and lists the combinations known to work.

Linux works with GCC 4.7 and later, Clang 3.2 and later, and the Intel compiler 15 and later. On the Mac it works with Apple Clang using libc++, and GCC works if you get 4.7 or later. Windows works with GCC 4.8 and later when pthread-win32 is present, and with Visual Studio 2013 and later.

The iOS row is the one to read twice. It works with Apple Clang using libc++, and there is a note that because iOS has no thread local support, the library uses a workaround based on pthreads.

That single note tells you a lot about how the library is built. A task framework typically needs per-thread state, and on iOS it cannot have thread-local storage, so it emulates it with pthreads. Emulated thread-local state is slower than real TLS and is the kind of thing that changes what you can assume about performance on that platform.

The Windows row has a similar shape: GCC works, but only with pthread-win32, which is a third-party POSIX threads layer. On a modern Windows toolchain, Visual Studio is the straightforward path and GCC needs that extra dependency.

So the compatibility story is good but not frictionless, and the two rows with caveats are exactly the two mobile and Windows cases where a team is most likely to hit them.

Wiki for the docs, CMake for the build, one example file

Everything that is not in the README is deliberately somewhere else, and the README tells you where.

Documentation is split into four wiki pages. Tasks describes the task objects, which the README says are the core of Async++ and strongly recommends reading first. Parallel algorithms covers running work on ranges in parallel. Schedulers covers the low-level details and how to customise them. The API Reference gives detailed descriptions of all the classes and functions.

That ordering is a hint about the intended depth. A newcomer is expected to understand tasks before touching schedulers, and the reference is a lookup rather than a tutorial.

Building and installing is also a wiki page rather than a README section. What the repository root shows is `CMakeLists.txt` and the `Async++Config.cmake.in` configuration template. That is a modern, correct choice.

The examples directory contains a single file, `gtk_scheduler.cpp`, which is more interesting than the count suggests. The repository lists it as the sole file under `examples/`.

The licence is MIT, the project is by Amanieu, and contact is by email. Release history is three tags: 1.0 on 2018-06-01, 1.1 on 2020-05-10 and 1.2 on 2024-10-11.

Editorial conclusion

Adopt Async++ if you are on C++11 and want structured task composition with the PPL shape, since the API is small and the platform matrix is documented. Verify first which compiler you have against the support list, because the iOS build uses a pthread workaround rather than thread-local storage and Windows needs pthread-win32 with GCC.

Frequently asked questions

Official sources

1. Amanieu/asyncplusplus on GitHub
2. Issues
3. License: MIT
4. README
5. Releases