-
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
MSVC Build Tools Version 14.52 Release Candidate Now Available
https://devblogs.microsoft.com/cppblog/msvc-build-tools-version-14-52-release-candidate-now-available/
https://redd.it/1x6w5li
@r_cpp
I tested whether a coding agent would use C++23 ranges without being told
Blog post: https://kemalbektas.dev/ai-modern-features/
I tested whether coding agents would actually use C++23 ranges without being told.
They mostly didn’t. What changed things much more than the surrounding codebase was a short AGENTS.md asking for modern C++.
https://redd.it/1x4uvpy
@r_cpp
C++ futures part 2: The mental model for std::promise, std::packaged_task
https://devblogs.microsoft.com/oldnewthing/20261013-00/?p=112769/
https://redd.it/1x5fgwq
@r_cpp
Cheap alternative to reboot parameters (nohz, rcu, isolcpus) for stable benchmarks
When no optimized VM is available, running benchmarks on a desktop is noisy. Generally the standard fix on local machines is to optimize the machine states (gov, epp, SMT, boost, pin freq, ..), benchmark protocol with "min elapsed time" as iterations count, memory_order_acquire/release, interleaved trials and spotify turned off, while we get a new cup of coffee to leave the CPU free...
we can do better with:
\- Selecting CPUs by noise via IRQ rate and scheduler load
\- Pinning it with sched_affinity or even better by containing the task inside a cgroup
\- Pushing steerable IRQs off your selected CPUs and holding irqbalance for the run
\- Blocking the SMT siblings of the selected CPUs
But no existing tool is aligning, so i created Goset, it is an automatic taskset that stabilizes benchmark runs using only what the running kernel already exposes. It even has a remote thread that reads per-CPU counters remotely from procfs/sysfs (IPI-free): IRQ counts, throttle count, CPU freq, context switches, migrations, run delay.
The basic usage doesn't need sudo and only select threads, pin and monitor telemetry.
Request a single thread and sched_affinity:
goset -n 1 -- ./mybench
Request 4 threads, task contain in cgroup, steer IRQs and block siblings:
sudo goset -n 4 -cgroup -steer -fence -- ./mybench
PS: this is best-effort for no reboot. NMIs, LOC timer ticks and anything the kernel won't move still land on your CPUs, but it removes the biggest chunk.
What you get is the quietest placement available directly on your desktop and the telemetry that lets you compare between runs; while keeping Spotify and your best vibe-code agent still writing essays-as-comments to describe a sum.
Anyway, it is called Goset and it is at: github.com/fior512/goset
https://redd.it/1x4audg
@r_cpp
FastNoise2: noise generation using SIMD and C++17
https://github.com/Auburn/FastNoise2
https://redd.it/1x46nyu
@r_cpp
cxvm: pin a GCC or Clang version per project on Linux (pyenv/nvm, but for C++ compilers)
I do embedded Linux work, and every few months a project needs a host GCC that my distro doesn't ship: usually one with the same major version as an old cross toolchain from a BSP. Building one by hand is tedious. Switching `gcc` with update-alternatives changes it for every project on the machine, which is worse.
So I wrote cxvm. It keeps as many GCC and Clang versions as you want under your home directory, and each project pins one:
```sh
cxvm install gcc@13 # GCC 13.4.0, into ~/.local/share/cxvm
cd my-project
cxvm use gcc@13 # pins gcc@13.4.0 in .cxvmrc, generates .cxvm/
cmake -S . -B build/gcc-13.4.0 -DCMAKE_TOOLCHAIN_FILE=.cxvm/toolchain.cmake
```
You commit `.cxvmrc`. Whoever clones the repo runs `cxvm install` and gets the same compiler.
Things I cared about:
- Nothing wraps the compiler. The generated toolchain file names real paths in the store, so the build still works if cxvm is off PATH or uninstalled.
- A program built with a GCC newer than the host's gets an rpath to that GCC's libstdc++. cxvm never sets LD_LIBRARY_PATH.
- Clang can use the libstdc++ of a GCC you choose: `cxvm use clang@19 --gcc gcc@13`.
- Every download is checked against a sha256 built into the binary, and a toolchain only enters the store after a smoke test. No root.
Clang comes from LLVM's official releases (11 to 18, plus every release since 19.1.0). GCC comes from xPack builds (8.5.0 and 11.2.0 to 15.2.0), or cxvm builds it from the GNU tarball. I've built 10.5.0 and 16.2.0 that way; releases back to 4.8.5 are in the catalogue but untested.
Limits: x86_64 Linux only, native compilers only, and the list of releases is compiled into cxvm, so a new GCC needs a new cxvm release. `cxvm link /opt/gcc-11` registers a compiler you already have.
It's a single static binary written in Rust. I built it with a lot of help from Claude Code; I made the design calls and tested it on real hosts myself.
Repo: https://github.com/AndreaRicchi/cxvm
It's 0.1.0, and I've only run it on Ubuntu 24.04 and 26.04. If it breaks on Fedora, Arch or anything else, I'd like to know, and also which versions or workflows you'd need next.
https://redd.it/1x42iuf
@r_cpp
ACCU Overload Journal 195 - October 2026
https://accu.org/journals/overload/overload195
https://redd.it/1x3qpht
@r_cpp
wxWidgets 3.2.12 and 3.3.4 Released
https://wxwidgets.org/news/2026/10/wxwidgets-3.2.12-and-3.3.4-released/
https://redd.it/1x3320f
@r_cpp
Right way to test async code
https://redd.it/1x2wqgz
@r_cpp
Opting in, and back out again
https://dryperspective.github.io/posts/opting-in/
https://redd.it/1x2hhim
@r_cpp
std::variant, operator== and pattern matching
I was thinking, wouldn't adding equality comparison support between `std::variant` and one of its unambiguous alternatives help simplify potential pattern matching designs?
For example, imagine something like this (hypothetical syntax):
std::variant<int, std::string> v = 42;
match (v) {
case 42 => handle_int();
case "hello" => handle_string();
case _ => handle_other();
}
The idea would be to take advantage of something C++ already has: `operator==`. At the end of the day, matching is fundamentally a comparison, so why not build on the existing equality semantics?
For `std::optional`, we can get this with its existing comparison operators and the most trivial pattern matching compiler support:
std::optional<int> o = 42;
match (o) {
case 42 => handle_value();
case std::nullopt => handle_empty();
case _ => handle_other();
}
// Which would translate to:
if (o == 42)
handle_value();
else if (o == nullopt)
handle_empty();
else
handle_other();
And if we had something like `std::match_projection<Subject, Pattern>`, we could also extract the actual matched value instead of having to manually call `std::get`, dereference an optional, etc.
Basically, after a successful comparison, `match_projection` would tell the compiler what to extract based on the subject and pattern types and we could optionally bind that value using something like a `as <declaration>` syntax.
For example:
std::optional<int> o = 42;
std::optional<int> other_opt = 42;
match (o) {
// No binding needed
case 42 => foo();
// match_projection<optional<int>, int> -> int&
case 42 as int& x => use(x);
// match_projection<optional<int>, nullopt_t> -> void
case std::nullopt => handle_empty();
// match_projection<optional<int>, optional<int>>
// -> optional<int>&
case other_opt as auto& x => use(x);
}
The same would apply to `std::variant`, assuming we also extend its `operator==` to support comparisons with individual alternatives:
match (v) {
case 42 as int& x => use(x);
case "hello" as std::string& s => use(s);
// Only need to define operator== for this helper for this to work
case indexed<0> => handle_any_int();
// Or under this form for the sake of disambiguation
case indexed<0>(10) => handle_ten();
// Also provide match_projection<indexed<0>> to enable binding
case indexed<0>(20) as int& x => use(x);
case _ => handle_other();
}
Here, `indexed<>` would just be a hypothetical helper for explicitly selecting which alternative to compare against. It would only need an appropriate `operator==` to work with matching, and a corresponding `match_projection` specialization if we also wanted to extract the alternative.
This way, the matching itself wouldn't need to know anything about `variant`, `optional` or even user-defined types. It would just use their equality operators, while `match_projection` would tell it what to extract when we actually want to bind something, which is just syntactic sugar.
I'm curious what you think about this approach. It feels like we could get quite a bit of useful pattern matching functionality without introducing too much new language machinery or convoluted new language traits and APIs.
Also do you think std::variant being equality comparable with instances of its alternatives would be an useful addition on its own?
std::variant<int, std::string> v = 42;
if (v == "not my string") ...
// Which is simpler than
if (std::holds_alternative<std::string>(v) && std::get<std::string>(v) == "not my string") ...
Syntax seems nice on its own...
https://redd.it/1x1wh77
@r_cpp
How to Fix autoconf-style Configuration Probing
https://build2.org/blog/fix-autoconf.xhtml
https://redd.it/1x0rchx
@r_cpp
Removed by Reddit
Removed by Reddit on account of violating the [content policy. ]
https://redd.it/1x0p0yv
@r_cpp
CppCast Episode 412 : Safety and Interoperability with Rust and C++
https://cppcast.com/safety_and_interoperability_with_rust_and_cpp/
https://redd.it/1x0lxha
@r_cpp
Which C++ Hashmap Should You Actually Use?
https://martin.ankerl.com/which-hash-map/
https://redd.it/1w72hhh
@r_cpp
C++ futures part 4: What if I want an immediate on-thread std::async?
https://devblogs.microsoft.com/oldnewthing/20261015-00/?p=112776/
https://redd.it/1x74ol4
@r_cpp
C++ futures part 1: The mental model
https://devblogs.microsoft.com/oldnewthing/20261012-00/?p=112767/
https://redd.it/1x4ref5
@r_cpp
[Release] slick-logger v2.2.0 — Lock-free asynchronous C++20 logging with multi-process shared-memory support
Hi r/cpp,
I'd like to share **slick-logger**, an MIT-licensed, header-only C++20 logging library I've been developing for latency-sensitive applications.
The goal is to keep logging overhead low on application threads while supporting practical features such as multiple sinks, file rotation, and logging across process boundaries.
**Highlights:**
* Lock-free MPMC queue with deferred formatting
* C++20 `std::format` support
* Multi-process logging through shared memory and a dedicated collector
* Multi-sink output, rotation, and customizable formatting
* Source-location capture and configurable runtime statistics
* Windows, Linux, and macOS support
* Available through vcpkg
**Benchmarks**
On an AMD Ryzen 9 5900HX running Windows 11, the published benchmarks measured 10.96 million producer-side logging calls/sec with eight producer threads and small messages, compared with 1.93 million for spdlog async under the tested configurations.
These numbers measure producer-side enqueue performance, not durable log throughput. Queue saturation may result in overwritten entries. The complete benchmark source, hardware details, and methodology are available in the repository.
I'd particularly appreciate feedback on the concurrency architecture, benchmark fairness, and multi-process logging design.
GitHub: [https://github.com/SlickQuant/slick-logger](https://github.com/SlickQuant/slick-logger)
Benchmarks: [https://github.com/SlickQuant/slick-logger/tree/main/benchmarks](https://github.com/SlickQuant/slick-logger/tree/main/benchmarks)
https://redd.it/1x4cqxl
@r_cpp
This C++ drama is crazy - Adobe votes no
https://www.youtube.com/watch?v=DEqx_NMMH9Q
https://redd.it/1x450fx
@r_cpp
New C++ Conference Videos Released This Month - October 2026 (Updated To Include Videos Released 2026-10-05- 2026-10-11)
C++Now
2026-10-05 - 2026-10-11
Signal Trees - A Deep Dive into a High-Performance Alternative to Queue-Based Task Scheduling - Michael Maniscalco - [https://youtu.be/ZRd\_XN3LGxo](https://youtu.be/ZRd_XN3LGxo)
Object Oriented Programming in Contemporary C++ - Steve Downey - https://youtu.be/m7gwSr27m74
Cutting Some Slack for our Programs - Lisa Lippincott - [https://youtu.be/xwnRPyRK5h4](https://youtu.be/xwnRPyRK5h4)
2026-09-28 - 2026-10-04
What Every C++ Programmer Needs to Know About AI - Jody Hagins - https://youtu.be/ZBXHPKVCa8E
SPL - Open Source, Constexpr Library for Composing Algorithms - John Bandela - [https://youtu.be/96AGjm3uwko](https://youtu.be/96AGjm3uwko)
Senders For Existing Asynchronous Interfaces - Dietmar Kühl - https://youtu.be/KB5Nfofgu2k
ACCU
2026-10-05 - 2026-10-11
Real-time Safety in C & C++ - Guaranteed by the Compiler! - Anders Schau Knatten - [https://youtu.be/FeYEO3PhEVY](https://youtu.be/FeYEO3PhEVY)
Modernizing Legacy Codebases Without Stopping the World - Peter Muldoon - https://youtu.be/w9k-L0GLLKM
Our Journey Toward a Fully Backward-Compatible, UB-Safe, ISO C++ - John Lakos - [https://youtu.be/whFzmXXhG5g](https://youtu.be/whFzmXXhG5g)
2026-09-28 - 2026-10-04
Refactoring Towards Structured Concurrency - Roi Barkan - https://youtu.be/ttoQfPP\_Gkg
Design Patterns - The Most Common Misconceptions (3 of N) - Klaus Iglberger - [https://youtu.be/bAsJvmtYZOg](https://youtu.be/bAsJvmtYZOg)
One Lib to Rule Them All and in the Darkness bindgen… - Antonello Palazzi & Kay Hicketts - https://youtu.be/9BpVjPKv02s
ADC
2026-10-05 - 2026-10-11
BEEPS and PORTS - Annoy Everyone in Your House While Building An Audio Synthesizer - Joseph Stewart - [https://youtu.be/bnIV2nyh-rg](https://youtu.be/bnIV2nyh-rg)
Hardware DSP Asset Inheritance and Evolution - Takeshi Kuwahara - https://youtu.be/yYukJpiFOOU
Field Recording - In Search for Perfect Sounds - Malin Arvidsson - [https://youtu.be/L5iZDi71VWU](https://youtu.be/L5iZDi71VWU)
2026-09-28 - 2026-10-04
Designing Interactive Music Experiences in XR - Kasson Crooker - https://youtu.be/J3sVHT8luKs
When (Not) to Patent Audio Software - Simon Hestermann - [https://youtu.be/stBB1JoKQiY](https://youtu.be/stBB1JoKQiY)
Distribution Strategies for Indie Audio Developers - From Plugin to Product - Dani Karanyi - https://youtu.be/Piar49uTjtg
https://redd.it/1x44cin
@r_cpp
cppreference-doc for Qt Creator
Release cppreference C++ v2025.12.01 · cristianadam/cppreference-doc
This is useful for the Qt Creator users that use it for C++ development.
https://redd.it/1x3vaja
@r_cpp
C++ Contracts
C++ contracts are a good thing, why are people saying it's a bad thing? Anybody who said we should delay is delaying progress.
https://redd.it/1x3pk1i
@r_cpp
VKRT NES Remaster — an open-source C++20 NES emulator with an observation-driven remastering pipeline
I'm an independent developer from Argentina. I'd like to share VKRT NES Remaster, a native NES emulator built with C++20 and AI-assisted engineering.
It features:
Native CPU, PPU, APU and mapper implementations.
Original (F1) and Remaster (F4) graphics modes.
Windows frontend with audio and controller support.
Open-source code with attribution licensing.
The remastering system is designed to improve visuals without modifying the emulated machine's behavior.
No commercial ROMs are included, and universal compatibility isn't claimed.
GitHub: https://github.com/FranTriems/VKRT-NES-Remaster
Feedback and contributions are welcome!
https://redd.it/1x31c6d
@r_cpp
Yantra: an LALR(1) parser generator for C++23
Yantra: an LALR(1) parser generator for C++23 that builds the AST first, then walks it top-down
Yantra is a parser generator: lexer, parser, and AST walker generation, all in one tool, no separate lexer generator needed.
The main thing that's different from Yacc/Bison/Lemon: most LALR tools run your semantic actions during parsing, as each rule reduces, bottom-up, so by the time an action runs you don't know what its parent looks like. Yantra always builds the whole AST first, then walks it top-down in a separate pass, so a parent's action can run before its children are visited. It's still LALR(1) under the hood, bottom-up, table-driven, the top-down walk is layered on top of that, not a trade-off for a different parsing algorithm the way ANTLR's LL(*) gets it for free.
A small example:
expr := expr(a) PLUS expr(b)
%{
std::cout << "Adding" << std::endl;
%}
expr := NUMBER(N)
%{
std::cout << "Number: " << N.text << std::endl;
%}
Running `1 + 2 + 3` through it prints `Adding`, `Number: 1`, `Adding`, `Number: 2`, `Number: 3`, the outer `Adding` fires first, because the whole tree already exists before any action runs.
A single grammar can also define multiple walkers (e.g. one emitting C++, another emitting Java, from the same parse), with the AST and walker classes generated for you either way.
C++23, MIT licensed, no dependencies beyond the standard library. It's young (0.y.z, pre-1.0) and single-maintainer, so there are real gaps, listed honestly in known\_limitations.md rather than glossed over.
GitHub: https://github.com/TantrixAuto/yantra
https://redd.it/1x2kqq0
@r_cpp
I’m Building Bursztyn OS a Polish Operating System From Scratch
I’m building Bursztyn OS, a Polish operating system written from scratch in C, C++ and assembly.
It is not based on Linux and it is not a distro or a skin over another OS. Bursztyn has its own kernel, its own BSP2 filesystem, its own BWS system call interface, trust levels called PZB 0–5, its own .bur program format and .cebula application packages.
Right now it already has a Live mode, an installer, basic GUI components, storage support, graphics support, networking, input devices and its own system architecture. I’m also working on better virtual machine support and hardware drivers.
The long-term plan includes integration with the Avocado programming language, more native system applications, developer tools and a complete desktop environment.
What it does not have yet: broad real-hardware support, a large software ecosystem, a fully polished modern GUI, and the stability needed for daily use.
It is still a long-term experimental project, but more and more parts are becoming real and usable instead of existing only as design ideas.
I’m curious what people here think: what would you want to see in a completely independent Polish operating system?
Link https://bursztynos.dimitalart.pl/
YouTube https://www.youtube.com/watch?v=KJOM9zIWBO0&list=PLACv3ft21RwQ
\#osdev #operatingsystem
https://redd.it/1x2dwjl
@r_cpp
Profiles for simplicity and guarantees - Bjarne Stroustrup - CppCon 2026
https://youtu.be/41USGJaGsAo?si=VyfCWkbUK5mhxe7G
https://redd.it/1x0quoq
@r_cpp
owl – a header-only C++23 HTTP framework where route patterns and handler extractors are checked at compile time (early, looking for contributors)
I've been building owl for about five weeks: a header-only C++23 HTTP framework on libh2o. Posting it now because other people's compilers and opinions are worth more than another week of mine.
Repo: [https://github.com/owl-cxx/owl](https://github.com/owl-cxx/owl)
**The idea**
A handler is a free function. Its parameters are extractors, and the route pattern is a structural NTTP, so the pattern is checked against the extractors when the route is registered:
owl::Response hello(owl::PathView<"name"> name) {
return owl::Response::ok(std::format("hello {}", name.value));
}
coro::task<owl::Response> hits(owl::State<AppState> app) {
co_return owl::Response::json(std::format(R"({{"hits":{}}})", ++app->hits));
}
auto router = owl::Router<AppState>::make()
.route<"/hello/{name}">(owl::get(hello))
.route<"/hits">(owl::get(hits));
A `PathView<"nmae">` typo, or a handler taking `State<Other>` on a `Router<AppState>`, is a compile error rather than a runtime 500. There are 30 `compile_fail/` tests that pin exactly which misuses must not compile; if one of them starts compiling, that is the bug.
Handlers can be coroutines and they stay on the worker's event loop: one `SO_REUSEPORT` listener per worker, Node-cluster style, and a coroutine always resumes on the thread it suspended on. Errors cross library boundaries as `std::expected`, never as exceptions.
Around the core: `coro` (lazy tasks, generators, schedulers, an I/O reactor), `fstr` (string literals as structural NTTPs), async SQLite/Postgres and Redis for handlers, Prometheus with HTTP RED recorded automatically, middleware layers (CORS, basic auth), WebSocket with a controller pattern, HTTP/1.1 + h2c, TLS termination. About 27k lines across 94 headers and 94 test files. MIT.
**What it is not**
Early. APIs move between commits, there are no tagged releases, and nothing has run in production. The README says "do not ship this" and means it.
No C++20 fallback: it leans on `std::expected`, `if consteval`, and structural NTTPs. GCC 14 on Linux, Apple clang on macOS. Ubuntu's clang 18 does not work: libstdc++'s `<expected>` wants a `__cpp_concepts` it does not report, and libc++ 18 has no floating-point `from_chars`.
**Where I'd like help**
* Build it on your platform and tell me where it breaks. libh2o-evloop must be built from h2o source (distros ship 2.2, owl targets 2.3). There is a dev image, `ghcr.io/owl-cxx/owl-dev`, so you do not have to.
* Three self-contained good-first-issues, each with a clear definition of done: `HEAD` falling back to a `GET` handler; a CORS preflight to an unregistered path currently gets a bare 404 with no CORS headers; shared ranges fallbacks for Apple libc++ 21, which has no `views::chunk`, `views::stride`, or `views::enumerate`.
* Opinions on the extractor design. A custom extractor is one `FromContext` specialization that answers either the value or a `KickToken` with a status. I'd like to know where that model breaks before more of the API hardens around it.
* macOS CI. There is no prebuilt image, so h2o would need a source build on every run.
What is next (HTTP client awaited on the worker loop, static files, graceful shutdown, WebSocket over HTTP/2, eventually C++26 reflection for `sql` row mapping) and what is deliberately not planned is in ROADMAP.md. Telegram and Discord links are in the README, or just open an issue.
Happy to answer anything about the design, especially the compile-time route checking and keeping coroutines on the loop.
https://redd.it/1x0q0d9
@r_cpp
Is there a way to search across all P and N papers throughout standardization history?
It would be nice if there was a single place to see where, for example, the keyword "SFINAE" shows up across the content of all papers, not just titles. Thanks!
https://redd.it/1w7n7k1
@r_cpp
VeloCache: A high-performance, Redis-compatible in-memory key-value store built from scratch in C++20 using kqueue and async I/O
Hi everyone,
I wanted to share a systems project I’ve been building solo: **VeloCache**. It’s a high-performance, Redis-compatible in-memory key-value store written from scratch in C++20, specifically optimized for macOS/BSD using native `kqueue`.
# Key Technical Architecture:
* **Asynchronous Networking:** A single `kqueue` event loop handles non-blocking TCP sockets, supporting pipelining and fragmented frames without spawning a thread per client.
* **Non-blocking Storage Thread:** The core storage engine, AOF logging, and replication updates are handled by a dedicated FIFO `BackgroundWorker` thread. Communication between the network loop and storage is done via a non-blocking `socketpair`.
* **Efficient TTL Indexing:** Deadlines are tracked via a `std::multimap<std::int64_t, std::string>`, ordered by absolute deadline. Erasing by iterator prevents O(N) database scans, giving amortized O(1) performance.
* **Durability:** Implements AOF persistence with 64-bit FNV-1a checksums and atomic snapshot installations (`mkstemp` \+ `rename`).
* **Asynchronous Replication:** Master/slave topology supporting `SYNC` streams, sequence validation, and explicit loading states.
I also wrote a zero-dependency TypeScript client using only the native Node.js `net` module for integration testing.
The project puts a lot of focus on POSIX resource boundaries, backpressure control (128 MiB / 1024 operations max queue budget), and edge-case test suites (covering everything from mid-flight replication drops to simulated slow-disk `fsync` injection via an interposition library).
The repository has a fully configured macOS CI pipeline. I would absolutely love to get some **brutal code review**, architecture critiques, or tips on performance optimization from the systems engineers here!
**Repo Link:** [https://github.com/geamnegru/VeloCache](https://github.com/geamnegru/VeloCache)
Thanks for reading!
https://redd.it/1x0kw4o
@r_cpp
Lazy Evaluation - Operators
https://breese.github.io/2026/09/04/lazy-operator.html
https://redd.it/1w7skdq
@r_cpp