Reviewers wanted: Corosio & Capy (coroutine-native I/O + coroutine foundation for C++20) are entering Boost formal review

The Boost formal review of **Corosio** and **Capy** begins today (June 23) and runs through July 7. The esteemed Jeff Garland is the review manager (Jeff also managed the Boost.Asio review back in the day!).

**What these libraries are:**

* **Capy** is a coroutine foundation library providing task types, execution contexts, executors, async synchronization primitives, buffer abstractions, and coroutine composition facilities.
* **Corosio** is a coroutine-native async I/O library built on top of Capy. Networking and I/O operations are designed specifically for C++20 coroutines, including awaitable operations, executor affinity, cancellation support, and cross-platform backends (IOCP, epoll, kqueue).

Together they're a coroutine-native alternative to the callback first model. Async code reads like sync without giving up control over execution, cancellation, or performance.

**Why this review matters:** Boost currently doesn't have a coroutine-native I/O library. If these are accepted, they'd be the first.

If you have opinions about how async I/O should work in C++, now's your chance to put them on the record. Both experienced Boost contributors and first time reviewers are encouraged to participate.

**Links:**

* Corosio:[ GitHub](https://github.com/cppalliance/corosio) ·[ Docs](https://develop.corosio.cpp.al/corosio/index.html)
* Capy:[ GitHub](https://github.com/cppalliance/capy) ·[ Docs](https://develop.capy.cpp.al/capy/index.html)
* Submitting your review: [https://go.boost.org/4vrwPbP](https://go.boost.org/4vrwPbP)

https://redd.it/1udgx1y
@r_cpp

coroutil queues: library-agnostic queues for C++20 coroutines

Repo: [https://github.com/tzcnt/coro\util](https://github.com/tzcnt/coroutil)

Documentation: [https://fleetcode.com/oss/coro\util/docs/queues/index.html](https://fleetcode.com/oss/coroutil/docs/queues/index.html)

coro\util is a collection of data structures for C++20 coroutines that aren't tied to any task or executor library. Each structure is a template that accepts a policy object which binds it to your library of choice. I've include pre-configured adapters for several libraries: YACLib, Boost.Cobalt, Asio, Boost.Capy, libfork, concurrencpp, cppcoro, and libcoro. Adding a custom adapter for your own library is also relatively simple, and I've provided an agent prompt that automates it.

These queues were all written for the TooManyCooks framework, which as far as I know, has the most complete suite of general purpose async data structures of any publicly available library. This first edition only includes the 5 queues. The next batch will include the control structures (mutex, semaphore, etc.). I've decided to port them to be dependency-free in an effort to advance the interoperability of the C++20 coroutine ecosystem, which IMO is too siloed right now. I aim to demonstrate and evangelize for a style of code that is "sans-executor/task".

All of the queues are lock-free and wait-free on the fast path, and offer purely zero-copy operation. They have been rigorously tested and examined over their lifetime in TooManyCooks, and I believe them to be production-ready.

https://redd.it/1udi88p
@r_cpp

Two Indexed Hash Tables
https://vnmakarov.github.io/data%20structures/c/c++/open-source/2026/06/23/two-indexed-hash-tables.html

https://redd.it/1udfuxj
@r_cpp

Building an ECS: Data Oriented Hierarchies
https://ajmmertens.medium.com/building-an-ecs-data-oriented-hierarchies-62fb2847d100

https://redd.it/1udo1us
@r_cpp

A policy-based Dependency Injection framework for C++26

# Looking for feedback on a policy-based compile-time DI framework for C++20

I've been working on a compile-time Dependency Injection framework for modern C++:

https://github.com/steumarok/cppdimanager

The main idea is a policy-based resolution pipeline where object creation, dependency injection, casting, lifetime management and scope creation are handled by independent compile-time policies.

Unlike traditional DI containers that are primarily organized around service lifetimes, the framework is built around the following pipeline:

Requested Type
      ↓
Resolution Policy
      ↓
Creation Policy
      ↓
Injection Policy
      ↓
Cast Policy
      ↓
Returned Type

Current features:

- Constructor injection
- Member injection
- Interface-to-implementation mapping
- Hierarchical containers
- Request-scoped dependencies
- Scoped object lifetimes
- Automatic factory injection (std::function<T()>)
- Compile-time registries
- Configurable resolution and creation policies

Example web application:

https://github.com/steumarok/cppdimanager/blob/main/example.cpp

I'm particularly interested in feedback about:

- Overall API design
- Lifetime and scope management
- Policy architecture
- Compile-time vs runtime trade-offs
- Potential simplifications
- Missing features compared to existing DI frameworks

Suggestions and criticism are very welcome.

https://redd.it/1udrt86
@r_cpp

Automated Unit Testing On-The-Cheap
https://freshsources.com/code-capsules/test-part1/

https://redd.it/1udt4by
@r_cpp

The Barrier in C++ 20 - concurrent programming example...
https://som-itsolutions.hashnode.dev/the-barrier-in-c-20-concurrency-the-programmer-in-me-is-still-thriving

https://redd.it/1ueapjq
@r_cpp

How to Create an MCP Server Aspect in C/C++
https://github.com/IBM/tsar-mcp/blob/main/mcp/doc/MCPServer_AspectGuide.md

https://redd.it/1ued912
@r_cpp

From-scratch C++ correlation-filter tracker for object detection, tracking and redetection (without OpenCV) for Raspberry Pi 5 targeting 100+ FPS - looking for advice from people who've pushed similar systems further.

Hey everyone,

I'm currently building a **real-time object tracker from scratch in C++17** for the **Raspberry Pi 5**, with the goal of achieving **100+ FPS** on CPU-only hardware. The project is based on **correlation filters** and **FFT-based signal processing**, with **no machine learning, no neural networks, and no OpenCV** in the core tracking pipeline.

The motivation is simple: a straightforward OpenCV-based implementation on the Pi only gets me around **15 FPS**, which seems far below what this class of algorithms should be capable of. From both the literature and projects I've come across, the gap appears to be in implementation and system overhead rather than the underlying tracking method itself.

# Current approach

Right now, my plan is to build the pipeline around:

* A custom image loading and preprocessing path to avoid unnecessary OpenCV decode/resize overhead.
* **FFT-based correlation in the frequency domain** for fast target localization.
* Adaptive online filter updates so the tracker learns appearance changes over time.
* **PSR (Peak-to-Sidelobe Ratio)** based confidence estimation for occlusion and tracking failure detection.
* A modular architecture that can later be extended with features like scale estimation and automatic re-acquisition.

The area I'm currently spending the most time researching is the FFT layer. I'm trying to determine whether the best approach on the Pi 5 is:

* a hand-written radix-2 FFT,
* aggressive **NEON/SIMD** optimization,
* or using an existing library such as **FFTW** or **kissFFT**.

# Other approaches I've been studying

To better understand the design space, I've also been looking into modern transformer-based visual trackers. They jointly process information from a target template and a search region, making them much more semantically aware and capable of handling challenging scenarios such as partial occlusions or target disappearance with automatic re-acquisition. The downside is that they are significantly heavier computationally and can be difficult to deploy efficiently on constrained edge hardware.

On the more classical side, I'm currently reading about **Discriminative Scale Space Tracking (DSST)**. One of the main limitations of basic correlation-filter trackers is that they often assume the target size remains constant. DSST addresses this by learning a separate correlation filter across multiple image scales, allowing the tracker to estimate changes in object size efficiently while still maintaining real-time performance. It seems like an elegant way to improve robustness without giving up the speed advantages that make correlation filters attractive in the first place.

Exploring these different approaches has been interesting because they represent very different trade-offs: transformer-based methods emphasize robustness and semantic understanding, while correlation-filter methods prioritize simplicity, efficiency, and extremely high throughput.

# Looking for advice from people who've built similar systems

If you've worked on **correlation-filter trackers**, **embedded computer vision**, **real-time image processing**, **high-performance C++**, **drone tracking**, or **ARM optimization**, I'd really appreciate your perspective.

Some questions I'm hoping to get insight on:

* Where did the biggest performance bottleneck actually end up being? The FFT itself, memory layout, cache locality, camera capture, frame copies, synchronization, or something else entirely?
* On Raspberry Pi 5 specifically, is hand-vectorizing FFTs and pointwise complex operations with **NEON** worth the effort, or do mature FFT libraries generally outperform custom implementations?
* If you've implemented trackers such as **MOSSE**, **ASEF**, **UMACE**, **DSST**, or related adaptive correlation-filter methods, what optimizations made the biggest practical

difference?
* Has anyone here managed to push a CPU-only tracker into the **100–300+ FPS** range on Raspberry Pi-class hardware? If so, what lessons did you learn that aren't obvious from reading papers?

# Future directions I'm considering

Beyond getting the core tracker running efficiently, some areas I'd like to explore include:

* DSST-based scale estimation.
* Lightweight re-detection and automatic target re-acquisition.
* More robust confidence estimation beyond PSR.
* Hybrid detector–tracker pipelines that combine fast tracking with occasional detection.
* FFT optimization, cache-aware memory layouts, and ARM/NEON-specific performance tuning.
* General techniques for squeezing the maximum performance out of embedded CPU-only vision systems.

I'm not looking for someone to redesign the project or suggest replacing it with deep learning. My goal is to understand where the real bottlenecks are and learn from people who've already built or optimized similar systems before I spend weeks optimizing the wrong component.

If you've worked on anything similar, or achieved high frame rates with classical tracking methods, I’d love to hear about your experience, benchmark results, profiling insights, or even things that *didn't* work. Thanks in advance!

https://redd.it/1ueepo7
@r_cpp

Tired of mutex hell and spaghetti event handlers? Here's a single-threaded FSM methodology that keeps your async logic clean — forever. Just #include "uniflow.hpp".

We've all been there. A module that starts simple —
connect, send, wait for ack — and six months later looks like this:

bool connecting_, connected_, cmd_sent_, waiting_ack_, draining_, fault_;

void Update() {
if (estop_) {
connecting_ = false;
cmd_sent_ = false;
waiting_ack_ = false;
// forgot draining_ — ghost ack bug waiting to happen
...
}
if (!connected_) { ... }
else if (!cmd_sent_) { ... }
else if (waiting_ack_) { ... }
// where does fault_ get handled? what if estop_ and fault_ fire together?
}

Flags that must move in pairs. Resets that get forgotten.
E-stop logic that has to know about every stage.
Two developers write the same flow in completely different shapes.

**uniflow** keeps what works about the tick-based FSM — cooperative,
single-thread, no mutex — and fixes what doesn't.

Each stage becomes a named step function:

StepResult Step1_Connect() { device_.BeginConnect();
return Next(UF_FN(Step2_WaitConnected)); }

StepResult Step2_WaitConnected() { if (!device_.IsConnected()) return Stay();
return Next(UF_FN(Step3_WaitRequest)); }

StepResult Step3_WaitRequest() { if (!input_.HasRequest()) return Stay();
device_.Send(input_.Take());
return Next(UF_FN(Step4_WaitAck)); }

StepResult Step4_WaitAck() { if (device_.HasAck()) return Done();
return StayUntil(3000ms, UF_FN(Step5_Timeout)); }

One function = one state. Entry is explicit. Transitions are pinned in code.
No hidden jumps. No forgotten resets. Brace depth stays flat forever.

---

**How it works**

One `Runtime` owns one pump thread. Attach as many modules as you want.
The pump visits each module once per round — cooperative, round-robin.

uniflow::Runtime rt;
Flow_XAxis x_axis{rt};
Flow_YAxis y_axis{rt};
Flow_Conveyor conveyor{rt};

x_axis.ctx_home_.StartFlow(); // start homing X
y_axis.ctx_home_.StartFlow(); // start homing Y — simultaneously, no thread, no mutex

Modules on the same Runtime share the single-thread invariant.
No locks needed. Ever.

The pump adapts its sleep to the situation:
- Back-to-back transitions? No sleep, full speed.
- Polling with Stay()? 20ms yield. CPU near 0.
- All idle? 1ms — ready to wake immediately.

External event arrives? Call `rt.Wake()` from any thread. No waiting out a sleep cycle.

---

**Blocking work? No problem.**

Heavy I/O goes to the built-in thread pool via SubmitAsync.
The pump never blocks. Every other module keeps running.

StepResult Step1_Fetch() {
AsyncId job = SubmitAsync(UF_FN(DoFetch), 5000ms, url_);
return Next(UF_FN(Step2_Process), job);
}

StepResult Step2_Process(AsyncId job) {
auto r = AsyncResult<std::string>(job);
if (r.pending()) return StayUntil(5000ms, UF_FN(Step_Timeout));
if (!r.ok()) return Fail();
data_ = *r.return_value;
return Next(UF_FN(Step3_Save));
}

---

**Built-in tracing — zero instrumentation code**

Because every execution is "a step function was called once,"
one measurement point inside the pump sees everything:

[JobWorker] FLOW START
[JobWorker] Entry -> Step2_Validate elapsed=0.01ms
[JobWorker] ASYNC SUBMIT CallApi
[JobWorker] ASYNC DONE CallApi wait=124.38ms
[JobWorker] Step2_Validate -> Step3_WaitSave elapsed=124.42ms
[JobWorker] FLOW END DONE wall=143.21ms

Which step, how long, where it slowed down — visible without touching your logic code.

---

**What it's not**

- Not Boost.Asio — no new type system to learn, zero deps, doesn't absorb your objects
- Not C++20 coroutines — C++17, and style is

enforced by the framework not left to each developer
- Not a replacement for your existing objects — sockets, handles, device drivers stay as-is

---

**Single header. Zero deps. C++17. Windows / Linux / macOS.**
Also ported to Python and C# with identical APIs.

Demos included:
- `city_traffic` — 15 cars + intersections on one thread, zero mutex
- `pick_and_place` — two pickers sharing a CNC zone with no collision

→ https://github.com/splendidz/uniflow

Feedback and questions welcome — especially from anyone who's felt this pain.

https://redd.it/1uegh80
@r_cpp

2026 EuroLLVM Developers’ Meeting Talks
https://www.youtube.com/playlist?list=PL_R5A0lGi1ABJTIK5_5MkvHDb12mUmpSz

https://redd.it/1uejyr7
@r_cpp

CPP Algorithm & Concurrency visualiser watch your code run step by step

Built a platform where you can visualise your own cpp code datastructure and concurrency side by side supported one

1D arrays — int\[\], int\[N\]
Dynamic arrays — std::vector<int>
2D arrays / matrices — int\[R\]\[C\], std::vector<std::vector<int>>
Maps — std::map<int,int>, std::unordered_map<int,int>
Sets — std::set<int>, std::unordered\_set<int>
Stacks / queues / heaps — std::stack<int>, std::queue<int>, std::priority_queue<int>
Concurrency (threads & mutexes) — std::thread, std::mutex
Linked lists & trees — self-referential structs (struct Node { int val; Node* next; } / { int val; Node *left, *right; })

Try it here https://8gwifi.org/online-cpp-compiler/

Feedback and Bug's Welcomed for Improvement

https://redd.it/1uer6p5
@r_cpp

UI Toolkit Slint 1.17 released with drag & drop, system tray icons, tooltips, two-way model bindings, and improved Node.js integration
https://slint.dev/blog/slint-1.17-released

https://redd.it/1ueqv5y
@r_cpp

How do you keep toolchain drift across windows, linux, and mac manageable at 30+ engineers?

We're about 30 engineers split across Windows and Linux, with a handful on macOS. All C++, CMake + Ninja as the build sytem. The compiler situation is where it gets messy. Someone's always on a slightly different version and it surfaces in the strangest ways, usually right before a release.

We've gone back and forth on a few approaches...pinning versions across machines, containerizing the build environment, leaning on build servers and treating local builds as second-class, or some mix. None feel clean. All have tradeoffs, and the tradeoff's shift depending on the platform.

What's held up at a similar scale?

https://redd.it/1uev7qr
@r_cpp

What are some things you don't like about C++?

I asked this question in the C programming sub too.

What are some things you don't like about C++

If you were to change some things about C++, add keywords, or other similar things,

what would you change? Replace? Add?

My most important question is about keywords. What keyword would you add ( even just describing its functionality) to help YOU as a programmer?

Thank you :)

https://redd.it/1uf1618
@r_cpp

Trip report: ACCU On Sea 2026
https://sandordargo.com/blog/2026/06/24/trip-report-accu-on-sea-2026

https://redd.it/1uf2ikq
@r_cpp

oh GOD, it's good to come back to C++

Just been going around vanilla javascript, php, perl, LUA, some C#, batchscript over and over for a year but finally came back to C++ and it's good to be home.

To some they find it agonizing with memory management, consts, function prototyping and what not.. some wouldn't even touch it but to me, it's like riding a bike. It's all coming back and I need that extra control! Besides MySQL.. this is it! 🔥🔥

https://redd.it/1uf9jev
@r_cpp

C++23 Dependency Injection library with automatic dependency building

I open-sourced my dependency injection library.
Link: https://github.com/n0F4x/redi

This was developed for my game engine.
- feature-rich dependency configuration
- optimized for fast compile time
- helpful error messages when a cyclic dependency is detected
- dependencies are automatically constructed - no need to register them by hand

I am giving this project to the community so that everybody can benefit. This kind of approach is mostly useful when dealing with intricate systems, such as a plugin system.
I welcome all kinds of feedback, as this was mostly a learning opportunity for me.
If you'd like to use this in your project but don't have access to the required compiler features, let me know, and I'll see if I can reduce the requirements.


https://redd.it/1uf9pcf
@r_cpp