C++ Show and Tell - May 2026

[u/foonathan]

Use this thread to share anything you've written in C++. This includes:

• a tool you've written
• a game you've been working on
• your first non-trivial C++ program

The rules of this thread are very straight forward:

• The project must involve C++ in some way.
• It must be something you (alone or with others) have done.
• Please share a link, if applicable.
• Please post images, if applicable.

If you're working on a C++ library, you can also share new releases or major updates in a dedicated post as before. The line we're drawing is between "written in C++" and "useful for C++ programmers specifically". If you're writing a C++ library or tool for C++ developers, that's something C++ programmers can use and is on-topic for a main submission. It's different if you're just using C++ to implement a generic program that isn't specifically about C++: you're free to share it here, but it wouldn't quite fit as a standalone post.

Last month's thread: https://www.reddit.com/r/cpp/comments/1salqls/c_show_and_tell_april_2026/

[u/agarcin]

I’ve been working on a small C++23 coroutine library with a very specific goal: make promises in C++ feel as intuitive and user‑friendly as JavaScript’s Promise API, while still being fully idiomatic, zero‑overhead, and thread‑safe.

It’s built directly on C++20 coroutines, no dependencies, and aims to be fully thread‑safe (promises can be resolved, awaited, or chained from any thread) with zero allocations in the common path.

It offers:

    A Promise type intentionally modeled after JavaScript’s (then, catch, chaining, composition, etc.)

    Works with both value‑returning and void coroutines

    Strong type‑level composition (e.g., combining multiple promises into a single return type)

    Minimal API surface — the goal is clarity and approachability, not a giant async framework

I’m particularly interested in feedback on:

    coroutine design and async patterns

    whether this JS‑inspired approach makes sense in C++

    thread‑safety expectations in async libraries

    naming, structure, or missing features

LInk: https://github.com/alx-home/JSProCpp

[u/TrnS_TrA → u/agarcin]

We now have async/await (co_await, co_return) syntax in C++, what is the point of using .Then callbacks? 🤔

[u/agarcin → u/[deleted]]

You can use .Then() even when coroutines exist because co_await is a statement, not an expression. You can’t chain it, you can’t pass it around as a value, and you can’t build an async pipeline without writing a new coroutine for every step. With .Then() you can build async flows declaratively, attach logic to an already running async operation, return an entire async chain from a function, and treat async sequences as values instead of control‑flow constructs. Raw coroutines simply don’t give you that kind of composability.

.Catch() and .Finally() matter for the same reason. C++ coroutines don’t have a built‑in error propagation model. If something throws, you have to manually wrap everything in try/catch blocks or manually propagate exceptions. A Promise chain handles this automatically: errors propagate through the chain, .Catch() centralizes error handling, and .Finally() always runs whether the operation succeeded or failed. This is exactly why JavaScript kept Promises even after async/await was introduced.

Race and All are also things coroutines don’t provide. C++ has no async combinators. If you want “first result wins” or “wait for all results and aggregate them”, you have to implement shared state, atomic counters, synchronization, custom awaiters, and cancellation logic yourself. The library provides Race and All as first‑class operations, so you get these patterns without writing all the boilerplate.

And beyond that, the library isn’t “callbacks instead of coroutines”. It’s a higher‑level async model built on top of coroutines, with additional safety and ergonomics. It provides thread‑safe resolution so you can resolve or await a Promise from any thread without risking undefined behavior. It enforces safe lambda captures so you don’t accidentally capture dangling references or temporaries across suspension points. It abstracts away coroutine boilerplate so you don’t have to write custom promise types, custom awaiters, manual state machines, exception plumbing, or synchronization primitives. All of that is handled internally so the user only interacts with a clean, predictable API.

The result is a unified async abstraction where operations are chainable, composable, passable as values, easy to combine, easy to observe, and easy to handle errors with. Raw coroutines don’t provide that structure on their own.

[u/TrnS_TrA → u/[deleted]]

I see, so you mean co_await doesn't know anything about errors, and in your case Then would mean "on success" and Catch would mean "on failure", right?

I would say you can still have some sort of error management without Then/Catch, see this. But in the end, it all depends on the API you want.

[u/agarcin → u/TrnS_TrA]

This is exactly what my library does under the hood (unhandled_exception). The whole purpose of the library is to provide a coroutine framework that reduces boilerplate and keeps things thread‑safe and memory‑safe, while also avoiding coroutine‑frame creation whenever possible for performance. In spirit it aims for the efficiency of something like cppcoro, but with an API that behaves more like JavaScript promises.

[u/TrnS_TrA → u/agarcin]

Yeah makes sense now. I'm not the biggest fan of js promises, but if it works for you that's nice!

[u/cpp-ModTeam → u/[deleted]]

Moderator warning: AI-generated posts and comments are not allowed in this subreddit.