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
https://github.com/IBM/tsar-mcp/blob/main/mcp/doc/MCPServer_AspectGuide.md
https://redd.it/1ued912
@r_cpp
GitHub
tsar-mcp/mcp/doc/MCPServer_AspectGuide.md at main · IBM/tsar-mcp
A zero-dependency native C framework for building Model Context Protocol (MCP) servers on edge and enterprise systems. TSAR-MCP servers are designed to be designed by AI. - IBM/tsar-mcp
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
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
* 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
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
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
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
- 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
GitHub
GitHub - splendidz/uniflow: Run dozens of concurrent flows on a single thread - a header-only C++17 cooperative-scheduling framework…
Run dozens of concurrent flows on a single thread - a header-only C++17 cooperative-scheduling framework (reactor + worker-pool), zero deps - splendidz/uniflow
2026 EuroLLVM Developers’ Meeting Talks
https://www.youtube.com/playlist?list=PL_R5A0lGi1ABJTIK5_5MkvHDb12mUmpSz
https://redd.it/1uejyr7
@r_cpp
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
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
8gwifi.org
Online C++ Compiler & Algorithm Visualizer - Free Online
Run C++ online and visualize algorithms step by step—watch arrays, vectors, maps, sets, stacks, queues, heaps, linked lists, trees, and threads animate as your code runs. Free online C++ compiler with a built‑in algorithm visualizer.
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
https://slint.dev/blog/slint-1.17-released
https://redd.it/1ueqv5y
@r_cpp
Slint
Slint 1.17 Released
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
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
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
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
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
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
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
https://sandordargo.com/blog/2026/06/24/trip-report-accu-on-sea-2026
https://redd.it/1uf2ikq
@r_cpp
Sandor Dargo’s Blog
Trip report: ACCU On Sea 2026
Once again, I got the chance to come to Folkestone, UK. I think this was my fifth time, but the first one at ACCU On Sea. Yes, there is no more C++ On Sea, there is no more ACCU in Bristol — they got merged into ACCU On Sea.
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
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
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
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
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
GitHub
GitHub - n0F4x/redi: An automatic dependency injection library
An automatic dependency injection library. Contribute to n0F4x/redi development by creating an account on GitHub.
**Has the AI coding era changed how we should evaluate C++ frameworks?**
# **Has the AI coding era changed how we should evaluate C++ frameworks?**
**Has the AI coding era changed how we should evaluate C++ frameworks?**
I’ve been thinking about this while working with U++ (formerly Ultimate++).
For a long time, discussions around U++ usually start with comparisons to frameworks like Qt, wxWidgets, or CMake-based stacks.
But I’m starting to think that in 2026, a more interesting question might be:
**Why might cohesive C++ ecosystems like U++ be well-suited to AI-assisted development?**
Modern AI coding tools don’t just generate isolated functions well—they tend to work better when the surrounding system is **consistent, structured, and predictable**. Less time spent stitching together unrelated libraries, build systems, and tooling often improves end-to-end results.
That’s where U++ [https://github.com/ultimatepp/ultimatepp](https://github.com/ultimatepp/ultimatepp) becomes interesting.
It’s not just a GUI toolkit. It’s an integrated C++ ecosystem that includes:
* cross-platform application framework
* native GUI (CtrlLib)
* Skylark web framework
* SQL abstraction layer
* package/build system (.upp / .var assemblies)
* integrated documentation system (Topic++)
* command-line builds (`umk`)
* and a design philosophy centered around value semantics and reduced pointer ownership complexity
One of the long-standing criticisms of U++ is that it effectively pushed developers toward TheIDE as the primary workflow environment.
I think that criticism is fair.
To address this more directly, I built a **VS Code extension for U++ (**`upp-umk`**)** [**https://github.com/arilect/upp-umk**](https://github.com/arilect/upp-umk), which brings U++ closer to a modern editor-based workflow.
It provides:
* **Assembly & package management** — browse, select, and create U++ packages from a sidebar UI
* **Build & run** — build and run projects with a single click or shortcut
* **Debug support** — build with debug symbols and launch GDB automatically
* **IntelliSense integration** — auto-generate `c_cpp_properties.json` and `compile_commands.json`
* **clangd support** — compile database generation with watch mode and auto-restart
* **Workspace management** — automatic `.code-workspace` creation per assembly
* **Configurable builds** — flags, link modes, output paths, and more
This effectively removes one of the biggest practical barriers people mention when trying U++: IDE lock-in.
There is also work around integrating U++’s documentation system (Topic++) into external editors, but the build/tooling integration is what makes the real difference in daily usage.
What I find interesting is not that U++ is “better” or “worse” than other C++ stacks, but that it represents a different design philosophy: **integration over composition**.
I’m curious how others see this.
As AI becomes a bigger part of development workflows, do you think tightly integrated ecosystems become more valuable? Or does flexibility from loosely assembled toolchains still win?
Would love to hear thoughts from people who have used Qt, wxWidgets, Boost, Unreal, or other large C++ ecosystems.
https://redd.it/1ufd21h
@r_cpp
# **Has the AI coding era changed how we should evaluate C++ frameworks?**
**Has the AI coding era changed how we should evaluate C++ frameworks?**
I’ve been thinking about this while working with U++ (formerly Ultimate++).
For a long time, discussions around U++ usually start with comparisons to frameworks like Qt, wxWidgets, or CMake-based stacks.
But I’m starting to think that in 2026, a more interesting question might be:
**Why might cohesive C++ ecosystems like U++ be well-suited to AI-assisted development?**
Modern AI coding tools don’t just generate isolated functions well—they tend to work better when the surrounding system is **consistent, structured, and predictable**. Less time spent stitching together unrelated libraries, build systems, and tooling often improves end-to-end results.
That’s where U++ [https://github.com/ultimatepp/ultimatepp](https://github.com/ultimatepp/ultimatepp) becomes interesting.
It’s not just a GUI toolkit. It’s an integrated C++ ecosystem that includes:
* cross-platform application framework
* native GUI (CtrlLib)
* Skylark web framework
* SQL abstraction layer
* package/build system (.upp / .var assemblies)
* integrated documentation system (Topic++)
* command-line builds (`umk`)
* and a design philosophy centered around value semantics and reduced pointer ownership complexity
One of the long-standing criticisms of U++ is that it effectively pushed developers toward TheIDE as the primary workflow environment.
I think that criticism is fair.
To address this more directly, I built a **VS Code extension for U++ (**`upp-umk`**)** [**https://github.com/arilect/upp-umk**](https://github.com/arilect/upp-umk), which brings U++ closer to a modern editor-based workflow.
It provides:
* **Assembly & package management** — browse, select, and create U++ packages from a sidebar UI
* **Build & run** — build and run projects with a single click or shortcut
* **Debug support** — build with debug symbols and launch GDB automatically
* **IntelliSense integration** — auto-generate `c_cpp_properties.json` and `compile_commands.json`
* **clangd support** — compile database generation with watch mode and auto-restart
* **Workspace management** — automatic `.code-workspace` creation per assembly
* **Configurable builds** — flags, link modes, output paths, and more
This effectively removes one of the biggest practical barriers people mention when trying U++: IDE lock-in.
There is also work around integrating U++’s documentation system (Topic++) into external editors, but the build/tooling integration is what makes the real difference in daily usage.
What I find interesting is not that U++ is “better” or “worse” than other C++ stacks, but that it represents a different design philosophy: **integration over composition**.
I’m curious how others see this.
As AI becomes a bigger part of development workflows, do you think tightly integrated ecosystems become more valuable? Or does flexibility from loosely assembled toolchains still win?
Would love to hear thoughts from people who have used Qt, wxWidgets, Boost, Unreal, or other large C++ ecosystems.
https://redd.it/1ufd21h
@r_cpp
GitHub
GitHub - ultimatepp/ultimatepp: U++ is a C++ cross-platform rapid application development framework focused on programmer's productivity.…
U++ is a C++ cross-platform rapid application development framework focused on programmer's productivity. It includes a set of libraries (GUI, SQL, Network etc.), and integrated development...
Examples of C++23 - The Complete Guide
More than 150 examples of C++23 can be found now at **www.cppstd23.com**.
I hope it helps.
https://redd.it/1uf407e
@r_cpp
More than 150 examples of C++23 can be found now at **www.cppstd23.com**.
I hope it helps.
https://redd.it/1uf407e
@r_cpp
Cppstd23
Nicolai M. Josuttis: C++23 - The Complete Guide
Programming with C++23 by Nicolai Josuttis
std::formatter specialization for smart pointers
Currently something like
std::uniqueptr<int> uptr = std::makeunique<int>(42);
std::sharedptr<int> sptr = std::makeshared<int>(42);
std::println("uptr: {}", uptr);
std::println("sptr: {}", sptr);
is ill formed because there is no specialization of std::formatter for smart pointer types.
On the other hand,
std::cout << "uptr: " << uptr << '\n';
std::cout << "sptr: " << sptr << '\n';
do work because ostream defines overloads for smart pointer types.
Please let me know if anyone has thoughts or if there's some reason that these types haven't been specialized that I'm missing.
https://redd.it/1ufjvur
@r_cpp
Currently something like
std::uniqueptr<int> uptr = std::makeunique<int>(42);
std::sharedptr<int> sptr = std::makeshared<int>(42);
std::println("uptr: {}", uptr);
std::println("sptr: {}", sptr);
is ill formed because there is no specialization of std::formatter for smart pointer types.
On the other hand,
std::cout << "uptr: " << uptr << '\n';
std::cout << "sptr: " << sptr << '\n';
do work because ostream defines overloads for smart pointer types.
Please let me know if anyone has thoughts or if there's some reason that these types haven't been specialized that I'm missing.
https://redd.it/1ufjvur
@r_cpp
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
Am I the only one who thinks this? (about enum)
The main differences between an
// Dummy wrapper struct
struct EnumName
{
enum Value
{
ZERO
};
// the scope is located in "EnumName"
// so you access "EnumName::ZERO"
};
https://redd.it/1uflgw3
@r_cpp
The main differences between an
enum and enum class|struct is that the latter has its own scope, but you lose the implicit operators from enum, and the closest to it is as presented. I wish that enum struct maintained the operators, acting like the C enum, but with it's own scope.// Dummy wrapper struct
struct EnumName
{
enum Value
{
ZERO
};
// the scope is located in "EnumName"
// so you access "EnumName::ZERO"
};
https://redd.it/1uflgw3
@r_cpp
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
Easy JSON ImGui Config Files for Hack Menus
https://youtu.be/2P7uSx7EA2c?si=9b-jpvqZvDQ6FL9E
https://redd.it/1ufucmg
@r_cpp
https://youtu.be/2P7uSx7EA2c?si=9b-jpvqZvDQ6FL9E
https://redd.it/1ufucmg
@r_cpp
YouTube
Easy JSON ImGui Config Files for Hack Menus
🔥 Learn How to Easily Save Config Files for ImGui Hack Menus
👨💻 Buy Our Courses: https://guidedhacking.com/register/
💰 Donate on Patreon: https://patreon.com/guidedhacking
❤️ Follow us on Social Media: https://linktr.ee/guidedhacking
🔗 Article Link: ht…
👨💻 Buy Our Courses: https://guidedhacking.com/register/
💰 Donate on Patreon: https://patreon.com/guidedhacking
❤️ Follow us on Social Media: https://linktr.ee/guidedhacking
🔗 Article Link: ht…
ACCU On Sea 2026 trip report, still with AI!
https://mropert.github.io/2026/06/24/accu_on_sea_2026/
https://redd.it/1ufx4ro
@r_cpp
https://mropert.github.io/2026/06/24/accu_on_sea_2026/
https://redd.it/1ufx4ro
@r_cpp
mropert.github.io
ACCU On Sea 2026 trip report, still with AI! · Mathieu Ropert
Two conferences in one. You can see France in the distance but then they pour wine from a can into plastic glass to remind you where you are.
Latches in C++ 20 concurrency - just like the CountdownLatch of Java concurrency package...
https://som-itsolutions.hashnode.dev/latches-in-c-20-concurrency-just-like-the-countdownlatch-of-java-concurrency-package
https://redd.it/1ufxmns
@r_cpp
https://som-itsolutions.hashnode.dev/latches-in-c-20-concurrency-just-like-the-countdownlatch-of-java-concurrency-package
https://redd.it/1ufxmns
@r_cpp
Som's Tech World...
Latches in C++ 20 concurrency - just like the CountdownLatch of Java concurrency package...
Multithreaded programming is inherently difficult. One of the reasons is that we can't have control over how a thread will start and finish, in which order - it all depends upon the thread scheduling