-
Stay up-to-date with everything C++! Content directly fetched from the subreddit just for you. Join our group for discussions : @programminginc Powered by : @r_channels
Amidst the LLM craze, does anyone still care about old machine learning algorithms?
I've built my own framework that allows embedding, quantization, and self-retraining on microcontrollers using C++ from scratch, currently mainly for tree-based model families (like Random Forest, xgboost...). It can compress and train the entire MNIST dataset of 70,000 images on ESP32 with only 3MB of RAM while still achieving an accuracy of up to \~94% across 10 classes (models size about 600 KB of RAM). This is intended to help the model adapt without having to reload the code into the microcontroller.
Everything is here, including source code, demo, and documentation: https://github.com/viettran-edgeAI/MCU
Although it's designed to handle tabular data, I chose to demo it with a simple computer vision application for visualization.
I spent a lot of time on this project, it didn't rely heavily on AI, and I can explain every line of code. I'm open to discussing anything. I hope everyone can provide some feedback or suggestions. In my country, it seems like now they only care about LLMs; every paper tries to cram LLMs in and they don’t care about these older algorithms anymore—they just brush them aside.
https://redd.it/1skdyr7
@r_cpp
Let's bite the Bullet: Module Units shouldn't implicitly import anything
https://github.com/abuehl/docs/blob/main/no-implicit-import.md
https://redd.it/1sk1x75
@r_cpp
References vs Pointers
https://slicker.me/cpp/references_pointers.htm
https://redd.it/1sjyh5l
@r_cpp
CMake Past, Present, and Future - Bill Hoffman, Kitware [29m25s]
https://www.youtube.com/watch?v=cD-JgncskTQ
https://redd.it/1sjoid3
@r_cpp
Building a Deep learning framework in C++ (from scratch) - training MNIST as a milestone
i am building a deep learning framework called "Forge" completely from scratch in C++, its nowhere near complete yet, training MNIST Classifier shows a functional core on CPU (i'll add a CUDA backend too). My end goal is to train a modern transformer on Forge.
YT video of MNIST training :- www.youtube.com/watch?v=CalrXYYmpfc
this video shows:
\-> training an MLP on MNIST
\-> loss decreasing over epochs
\-> predictions vs ground truth
this stable training proves that the following components are working correctly:-
\--> Tensor system (it uses Eigen as math backend, but i'll handcraft the math backend/kernels for CUDA later) and CPU memory allocator.
\--> autodiff engine (computation graph is being built and traversed correctly)
\-->primitives -- linear layer, relu activation (Forge has sigmoid, softmax, gelu, tanh and leakyrelu too), CrossEntropy loss function (it fuses log softmax and CE. Forge has MSE and BinaryCrossEntropy too, the BCE fuses sigmoid and BCE) and SGD optimizer (i am planning to add momentum in SGD, Adam and AdamW)
[the Forge repo on GitHub is currently private as its WAP\]
My GitHub: github.com/muchlakshay
https://redd.it/1silamh
@r_cpp
Is Modern C++ Actually Making Us More Productive... or Just More Complicated?
Quick one that's been on my mind: with C++20/23 throwing ranges, coroutines, concepts, and modules at us, are we actually making the language better for real-world work… or just stacking more complexity on top of an already complicated beast?
Some of these features are genuinely cool and I use them, but I keep wondering if we're scaring off new devs while old codebases stay frozen in C++98 forever. Is modern C++ a net win for productivity, or are we over-engineering?
What do you think? Love it, hate it, or somewhere in between?
https://redd.it/1sihs1w
@r_cpp
HPX Tutorials: Performance analysis with VTune
https://www.youtube.com/watch?v=ddLCrNEZhts
https://redd.it/1shqr6c
@r_cpp
We benchmarked sender-based I/O against coroutine-based I/O. Here's what we found.
When I/O operations return senders, they incur an unnecessary per-operation allocation. This explains why.
|Stream Type|capy::task|bex::task|sender pipeline|
|:-|:-|:-|:-|
|Native|0|0|0|
|Abstract|0|1|1|
|Type-erased|0|1|1|
When an I/O stream is type-erased, sender/receiver's connect() produces an operation state whose type depends on both the sender and the receiver. The size is unknown at construction time. It must be heap-allocated per operation. Under awaitables, await_suspend takes a coroutine_handle<> — the consumer type is already erased — so the awaitable can be preallocated once and reused. The allocation cannot be eliminated. It follows from connect producing a type that depends on both the sender and the receiver.
We measured this. The benchmark executes 20,000,000 read_some calls per configuration on a single thread using a stream that isolates the execution model overhead from I/O latency. Five independent runs plus warmup; values are mean ± standard deviation. The benchmark source is public:
https://github.com/cppalliance/capy/tree/develop/bench/beman
Anyone is invited to inspect the code, suggest improvements, and help make it better. The architects of P2300 are especially welcome — their expertise would strengthen the comparison.
Two papers address the cost asymmetry. P4003R0 "Coroutines for I/O" defines the IoAwaitable protocol for standard I/O operations. P4126R0 "A Universal Continuation Model" is purely additive — it gives sender/receiver pipelines zero-allocation access to every awaitable ever written. Together they make coroutines and senders both first-class citizens of the I/O stack.
# Benchmark Results
All values are mean ± stddev over 5 runs (warmup pass discarded). Each table measures one execution model consuming two I/O return types (awaitable and sender). The native column is the model's own I/O type; the other column goes through a bridge.
# Table 1: sender/receiver pipeline
|Stream Type|sender (native)|awaitable (bridge)|
|:-|:-|:-|
|Native|34.3 ± 0.1 ns/op, 0 al/op|46.3 ± 0.0 ns/op, 1 al/op|
|Abstract|47.1 ± 0.2 ns/op, 1 al/op|46.4 ± 0.0 ns/op, 1 al/op|
|Type-erased|57.5 ± 0.0 ns/op, 1 al/op|54.1 ± 0.1 ns/op, 1 al/op|
|Synchronous|2.6 ± 0.3 ns/op, 0 al/op|5.1 ± 0.1 ns/op, 0 al/op|
# Table 2: capy::task
|Stream Type|awaitable (native)|sender (bridge)|
|:-|:-|:-|
|Native|31.4 ± 0.2 ns/op, 0 al/op|48.1 ± 0.3 ns/op, 0 al/op|
|Abstract|32.3 ± 0.2 ns/op, 0 al/op|72.2 ± 0.2 ns/op, 1 al/op|
|Type-erased|36.4 ± 0.1 ns/op, 0 al/op|72.1 ± 0.0 ns/op, 1 al/op|
|Synchronous|1.0 ± 0.2 ns/op, 0 al/op|19.0 ± 0.0 ns/op, 0 al/op|
# Table 3: beman::execution::task
Note: bex::task's await_transform calls the sender's as_awaitable member directly when available, bypassing connect and start. Table 3's native sender column measures the as_awaitable path, not the full sender protocol.
|Stream Type|sender (native)|awaitable (bridge)|
|:-|:-|:-|
|Native|31.9 ± 0.0 ns/op, 0 al/op|43.5 ± 0.1 ns/op, 1 al/op|
|Abstract|55.2 ± 0.0 ns/op, 1 al/op|43.4 ± 0.0 ns/op, 1 al/op|
|Type-erased|55.2 ± 0.0 ns/op, 1 al/op|48.7 ± 0.1 ns/op, 1 al/op|
|Synchronous|1.0 ± 0.2 ns/op, 0 al/op|2.9 ± 0.2 ns/op, 0 al/op|
The full formatted report with detailed analysis is here: https://gist.github.com/sgerbino/2a64990fb221f6706197325c03e29a5e
# Analysis
Native performance is equivalent. Both models achieve \~31–34 ns/op with zero allocations when consuming their native I/O type on a concrete stream. There is no inherent speed advantage to either model at the baseline.
Type erasure costs diverge. capy::any_read_stream adds \~5 ns/op and zero allocations. The awaitable is preallocated at stream construction and reused across every read_some call. This is possible because
Why do SBOM tools keep getting C++ wrong? Is anyone actually solving this?
Ran into this again recently and curious if others have hit the same wall.
The structural problem: every mainstream approach answers "what did this build use?" at the wrong time.
Pre-build scanners read your manifests and build scripts. They report declarations, not execution. Miss vendored code, anything downloaded at configure time, conditional compilation paths that only activate on certain platforms.
Post-build binary analysis is better for dynamic deps but falls apart on statically linked code. Once the linker's done its job, the symbols are stripped and version info is gone. You know something's in there. You can't always tell what.
Someone ran Syft against OpenCV recently as a sanity check — 92 components, with FFmpeg flagged 6 times as a build component. FFmpeg is never compiled into OpenCV. Optional, platform-specific, loaded at runtime if available. The actual vendored deps in 3rdparty/ mostly didn't show up.
The gap is structural, not a tooling bug. You're trying to capture build-time information before or after the build exists.
Curious how others are handling this — especially on embedded or automotive stacks where static linking is basically the default. Is anyone doing something smarter than scanner + manual review?
https://redd.it/1sha7b8
@r_cpp
Writing only decoupled code
https://middleraster.github.io/DAG/HeaderOnlyNoForwardDeclarations.html
https://redd.it/1sh0wvt
@r_cpp
Per-op allocs: can we get these all to zero?
The benchmark builds read streams at three abstraction levels on beman::execution and beman::execution::task to measure per-operation cost and allocations across execution models.
Per-operation allocation counts for I/O read_some, three stream abstraction levels:
awaitable (capy::task) native: 0 abstract: 0 type-erased: 0
sender (pipeline) native: 0 abstract: 1 type-erased: 1
sender (beman::task) native: 0 abstract: 1 type-erased: 1
The awaitable path preallocates at stream construction because coroutine_handle is already type-erased. The sender path heap-allocates per operation because connect produces a type-dependent operation state.
github.com/cppalliance/capy/tree/develop/bench/beman
Can someone help me get the sender rows to zero?
Here's a more detailed supporting analysis:
https://gist.github.com/sgerbino/2a64990fb221f6706197325c03e29a5e
https://redd.it/1sgvh2o
@r_cpp
Managing Versions Programmatically with LibGit2
https://www.youtube.com/watch?v=Vrc95KdNHHA
https://redd.it/1sgsi0g
@r_cpp
Jumpstart to C++ in Audio C++ Online 2026 Workshop
https://cpponline.uk/workshop/jumpstart-to-cpp-in-audio/
https://redd.it/1sgn5sb
@r_cpp
0xd34df00d/you-dont-know-cpp: and neither do I
https://github.com/0xd34df00d/you-dont-know-cpp
https://redd.it/1sgf6tx
@r_cpp
Hashing in C++26
https://blog.infotraining.pl/hashing-in-cpp-26
https://redd.it/1sfmsm9
@r_cpp
std::pmr::generator, a generator without heap allocation
https://a4z.noexcept.dev/blog/2026/04/13/pmr-generator.html
https://redd.it/1skas3i
@r_cpp
The Global API Injection Pattern
https://www.elbeno.com/blog/?p=1831
https://redd.it/1sjzwaf
@r_cpp
Deciding 3rd party library
Hi all,
How do you people decide which opensource 3rd party library to include in a production environment, e.g for logging I can use either spdlog, Quill, Log4cplus, etc
Not every system is a HFT, in a general production system, how would you usually decide a library, practically speaking, I can get the logs through all of them but which one you would choose, I just took example of logger libs, it can be anything, I would like to understand how you all come to conclusion! do you usually study the whole library before using it?
https://redd.it/1sjrx2w
@r_cpp
400 page C++ full notes for beginners Available on Stuvia
A friend uploaded 400 page C++ notes for beginners who are just starting out with C++ programming and want clear and easy to understand explanations. Send me DM if you're interested.
https://redd.it/1siokcv
@r_cpp
I implemented UFCS in clang. Why it is cool, and why it will never come to C++.
https://github.com/ZXShady/zxshady.github.io/blob/main/ufcs.md
https://redd.it/1sik2vn
@r_cpp
I built a real-time N-body gravity simulator in C++/OpenGL — physically accurate with 4th-order Yoshida integration
Yo Reddit!
Finally shipping something I've been building for a while — a gravitational N-body simulator where I was pretty obsessed with making the physics realistic.
The integrator is Yoshida 4th-order symplectic — a step above Velocity Verlet. It runs 3 force evaluations per time step with coefficients derived to cancel lower-order error terms, giving much better long-term energy conservation for orbital sims.
Everything else in real units:
\- G = 6.674×10⁻¹¹ in full SI throughout
\- Planetary masses from real solar mass ratios
\- Orbital distances in real AU, time steps of 1 real day
\- Initial velocities from v = √(GM/r) so orbits are correct from frame 1
\- Momentum-conserving mergers when bodies collide
\- Live readout of speed in km/s and distance in AU — verifiable against NASA
Built with C++17, OpenGL 4.6, GLFW, GLM, ImGui, and stb_easy_font. Runs on Windows and Linux.
Would love any feedback — code structure, physics mistakes, whatever. I also have a bunch of open tickets if anyone wants to jump in (CMake, planet textures, Lagrange points...). And if you dig it, a star on the repo would make my day!
GitHub: https://github.com/kikikian/orrery
https://redd.it/1siaqgc
@r_cpp
await_suspend takes a type-erased coroutine_handle<> — the consumer type is already erased, so the awaitable's size is known at construction time. The sender equivalents add \~21–23 ns/op and one allocation per operation. The sender's connect(receiver) produces an op_state whose type depends on both the sender and the receiver. Since either may be erased, the operation state must be heap-allocated.
Bridges are competitive. Both bridges add 11–17 ns for native streams with zero bridge allocations. The allocations visible in the bridged columns come from the target model's own machinery (type-erased connect, executor adapter posting), not from the bridges themselves.std::execution provides compile-time sender composition, structured concurrency guarantees, and a customization point model that enables heterogeneous dispatch. These are real achievements for real domains — GPU dispatch, work-graph pipelines, heterogeneous execution. Coroutines serve a different domain. They cannot express compile-time work graphs or target heterogeneous dispatch. What they do is serial byte-oriented I/O — reads, writes, timers, DNS lookups, TLS handshakes — the work that networked applications spend most of their time on.
# Trade-off Summary
|Feature|IoAwaitable|sender/receiver|
|:-|:-|:-|
|Native concrete performance|\~31 ns/op, 0 al/op|\~32–34 ns/op, 0 al/op|
|Type erasure cost|\+5 ns/op, 0 al/op|\+21–23 ns/op, 1 al/op|
|Type erasure mechanism|preallocated awaitable|heap-allocated op_state|
|Why erasure allocates|it does not|op_state depends on sender AND receiver types|
|Synchronous completion|\~1 ns/op via symmetric transfer|\~2.6 ns/op via trampoline|
|Looping|native for loop|requires repeat_until \+ trampoline|
|Bridge to other model (native)|\~17 ns/op, 0 al/op|\~12 ns/op, 1 al/op|
|Bridge to other model (erased)|\~36 ns/op, 1 al/op|\~12 ns/op, 1 al/op|
https://redd.it/1shmwzz
@r_cpp
Freestanding standard library
https://www.sandordargo.com/blog/2026/04/08/cpp-freestanding
https://redd.it/1she4xf
@r_cpp
Interesting point of view from Daniel Lemire
If you’re not already familiar with Daniel Lemire, he is a well-known performance-focused researcher and the author of widely used libraries such as simdjson.
He recently published a concise overview of the evolution of the C and C++ programming languages:
https://lemire.me/blog/2026/04/09/a-brief-history-of-c-c-programming-languages/
It’s a worthwhile read for anyone interested in the historical context and development of systems programming languages.
https://redd.it/1sh7zxn
@r_cpp
C++23 Support in MSVC Build Tools 14.51
https://devblogs.microsoft.com/cppblog/c23-support-in-msvc-build-tools-14-51/
https://redd.it/1sh074n
@r_cpp
Why committee doesn't decide on a package format?
Why pkgconf or cmake package or CPS isn't officially endorsed by the committee?
Can't cmake or meson guys, who go to meetings and conferences pressure the higher ups to get something accepted?
Multiple build systems are ok, multiple package formats are not. Why no one solves this issue?
https://redd.it/1sgkyog
@r_cpp
Orbit - a fast lock-free MPMC queue in C++20
Orbit is a single-header lock-free MPMC bounded queue, designed from first principles and tuned to get the most out of modern hardware. In my benchmarks, it consistently outperforms other implementations like atomic_queue, moodycamel::concurrent_queue or xenium::ramalhete_queue on both x86 and ARM, often by a significant margin.
## Key features
- Cross-platform: Support for x86/ARM, GCC/Clang/MSVC
- Supports any default-constructible type, not just atomics, with move semantics for non-trivially-copyable types
- Configurable to optimise for either latency or throughput
- Simple and versatile interface
- Easily tunable spin pause lengths for different platforms
I wrote a technical blog post covering the implementation details and optimisation process if you are interested.
https://redd.it/1sfqu2h
@r_cpp
beast2 networking & std::execution
I was looking for a new networking layer foundation for a few of my projects, stumbled on beast2 library which looks brand new, based on C++20 coroutines. I used boost.beast in the past which was great. Here's the link https://github.com/cppalliance/beast2. I also considered std::execution since it seems to be the way to go forward, accepted in C++26.
Now, what got me wondering is this paragraph
>The C++26 std::execution API offers a different model, designed to support heterogenous computing. Our research indicates it optimizes for the wrong constraints: TCP servers don't run on GPUs. Networking demands zero-allocation steady-state, type erasure without indirection, and ABI stability across (e.g.) SSL implementations. C++26 delivers things that networking doesn't need, and none of the things that networking does need.
Now I'm lost a bit, does that mean std::execution is not the way to go for networking? Does anyone have any insights on cppalliance research on the matter?
https://redd.it/1sgjube
@r_cpp
std::core_dump - The Newsletter of Boost and the C++ Alliance - April 2026
https://dl.cpp.al/newsletters/boost-newsletter-2026-04.pdf
https://redd.it/1sfzsr8
@r_cpp
Inside Boost.Container: comparing different deque implementations
I put together a comparison of std::deque internals across libc++, libstdc++, MSVC STL, and boost::container::deque (Boost 1.90). The article looks at the internal data structures, member layouts, sizeof(deque), and includes some benchmarks on common operations.
Boost 1.90 shipped a complete rewrite of its deque — the old SGI-derived layout was replaced with a more compact design (32 bytes vs the previous 80). The article digs into what changed, how the new implementation compares to the three standard library implementations, and how much block size alone affects performance across all of them.
https://boostedcpp.net/2026/03/30/deque/
https://redd.it/1sf210b
@r_cpp