What makes a game tick? Part 9.5 - The Curse of the Scheduler Latency · Mathieu Ropert
https://mropert.github.io/2026/10/20/making_games_tick_part9_5/

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

variable-length demangler for mangled C++ names
https://github.com/core-explorer/itanium-demangler

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

Project Building AxisOS: A Debian-based distro with a custom Wayland/Qt6 DE and bespoke package manager. Looking for contributors

Hey

I'm a software engineering student and I've recently started working on AxisOS, a new open-source Linux operating system project.

I'm currently at the foundational stage and am looking to build a team of contributors who want to get their hands dirty with C/C++, Wayland, and low-level Linux systems architecture.

The Stack & Architecture:
Base: Debian (leveraged for underlying hardware compatibility and core library stability).

Display & Desktop Environment: A custom Wayland compositor (utilizing ⁠wlroots⁠) paired with a native Qt 6 desktop interface, built entirely in C++.

Package Management: I'm developing a custom ⁠.axis⁠ package manager to handle specific software deployment pipelines and dependency resolution alongside the Debian base.

Current Status:
The project is in its early infancy. Right now, the focus is strictly on foundational architecture—specifically getting the Wayland compositor logic to behave and scaffolding the core build scripts for the ⁠.axis⁠ package manager.

Who I'm looking for:
If you're interested in systems programming and want a mostly blank canvas to experiment on, I'd love to collaborate. I'm specifically looking for:

C++ Developers: To tackle the compositor, package manager backend, and system utilities.

Qt 6 / UI Developers: To help architect and build the native desktop environment components.

Linux Architecture Enthusiasts: Anyone interested in build systems, init processes, shell configuration, and OS bootstrapping.

Whether you're an experienced systems engineer looking for a hobby project or a fellow student wanting to learn low-level Linux architecture by building it, you are welcome to join.

You can check out the current progress and source code here: https://github.com/jackyphuti/AxisOS
If you're interested in contributing, have architectural advice, or just want to tell me why building a custom package manager is a terrible idea, drop a comment or shoot me a DM!

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

Sharing my modern C++ project template , looking for feedback, suggestions, and contributors!
https://github.com/dr3mro/cpp-template

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

What is Modern C++ to you?

I keep hearing "modern C++." I've even used the term myself. And now I find I am questioning my use of the term.

1. What does "modern C++" really mean, specifically?
2. How many more years need to pass before it becomes just "C++?"
3. If "modern C++" is a thing then what is the other thing. Is it "old C++," or "legacy C++?"
4. Is C++ the only language that has a "modern" version?
5. If the answer to 4 is yes, why is C++ unique?


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

The public prerecordings for Meeting C++ 2026 are starting!
https://meetingcpp.com/meetingcpp/news/items/The-prerecordings-for-Meeting-Cpp-2026-are-starting-.html

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

Valgrind 3.28 RC1

An RC1 tarball for 3.28.0 is now available at https://sourceware.org/pub/valgrind/valgrind-3.28.0.RC1.tar.bz2
https://sourceware.org/pub/valgrind/valgrind-3.28.0.RC1.tar.bz2.asc

Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt

Please give it a try in configurations that are important for you and report any problems you have via our bug tracker at https://bugs.kde.org/enter\_bug.cgi?product=valgrind

See the NEWS file for a list of changes and bugfixes https://sourceware.org/git/?p=valgrind.git;a=blob;f=NEWS;h=be8b91b474e71535f272e8f11f1f6d1d35826ed3;hb=HEAD

Unless showstopper bugs are found (and cannot be easily fixed) the final 3.28.0 release is scheduled for this Fri Oct 23.

Note that our mailinglists at sourceforge.net seem to currently be unavailable. Not a great time to have that problem...

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

What's the difference between cppreference .com and .net?

My duckduckgo googling started giving me both, I don't understand the difference and don't remember which one is the original

They both look exactly the same
.com has en. at the beginning
.net doesn't have accounts

.net has the picture, .com doesn't

---

Is it a typosquash, is one of them fake, what's going on?

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

Home - libwinui
https://libwinui.com/

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

Microsoft CppCon 2026 Trip Report
https://devblogs.microsoft.com/cppblog/microsoft-cppcon-2026-trip-report/

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

Did my first c++ code

I did my first ever code yesterday in my computer programming university class. It's conversion of number of days to it's equivalent years and weeks. I'm not even exaggerating when I say that it inspired me so much, I want to learn more.

I've always wanted to learn coding and robotics but it always looked hard but now I want it more than ever

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

What You Can Do with an Array of Arrays
https://dalerank.github.io/en/articles/array-of-arrays.html

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

These Bees Make the Wrong C++
https://dalerank.github.io/en/articles/wrong-cpp-bees.html

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

Revisit Safe C++

Everyone is aware of the deluge of vulnerabilities now hitting critical software. It even makes the mainstream news, so software safety is coming onto politician's radars.

If this gets worse, I think it is not inconceivable that at some point memory safe software becomes mandatory. Or at least for software that is "reachable" from the internet.

So is it time to revisit Sean Baxter's Safe C++? Start out with a safe context ("safeexpr") and expand from there, just like constexpr.

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

A complete universal quantum computer simulator programmed in cpp
https://store.steampowered.com/app/2802710/Quantum_Odyssey/

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

CxxDox, a mkdocs plugin for complex C++ projects [Github/Apache2.0]
https://github.com/kfrlib/cxxdox/

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

Designing a Lightweight Closure for coost: Performance, Generality, and a Few Clever Tricks

In [coost](https://github.com/idealvin/coost), you can create coroutines using `go` in a way similar to Golang. The `go` function could initially be designed as:

```cpp
void go(void (*f)());
void go(void (*f)(void*), void* param);
```

However, this design only accepts two fixed function types and cannot support class member functions or other callable objects, making it insufficiently flexible.

If `go` were designed as:

```cpp
void go(const std::function<void()>&);
```

it would be more general, but constructing a `std::function` is relatively expensive, and its internal heap memory allocation is uncontrollable. This is unacceptable for coost, which pursues performance.

Therefore, to balance performance and usability, coost needs to implement its own closure class. In earlier versions, coost used an implementation based on virtual functions and inheritance, but it was not general enough and was limited to internal use.

Recently, I happened to have some free time. After thinking deeply about it, I redesigned the `closure` class. The design goals were as follows:

1. Do not use virtual functions or inheritance;
2. It should not be a template class;
3. `sizeof(closure) == sizeof(void*)`, i.e. it contains only one ordinary pointer member, making it easy to pass to the coroutine scheduler through `go`;
4. Support arbitrary functions with no return value (including non-static member functions of classes), with any number of parameters;
5. Optimize simple no-argument functions such as `void f()` as much as possible to avoid dynamic memory allocation.

According to goals 2, 3, and 5 above, `closure` can initially be designed as:

```cpp
struct closure {
closure(void (*f)()) noexcept : _p((void*)f) {}

void* _p;
};
```

The class contains only one pointer member `_p`. For function pointers of type `void(*)()`, the pointer is stored directly in `_p`; for other function types with parameters, a block of memory needs to be allocated to store the function address and parameters, and `_p` points to that memory.

The problem is how to distinguish which of the above cases is stored in `closure`. **Ordinary function addresses are not necessarily 4-byte or 8-byte aligned, so tagged-pointer techniques cannot be used** (i.e. writing a tag into the spare low bits of a pointer).

For the second kind of function, the one with parameters, `closure` calls `co::alloc` from coost's built-in memory allocator, and small memory blocks allocated by `co::alloc` are always 16-byte aligned. Therefore, if `_p` is not 16-byte aligned, it must store an ordinary no-argument function address. But if `_p` is 16-byte aligned, it is still impossible to distinguish the two cases.

It seems that some unconventional trick is required to solve this problem. Based on the discussion above, `_p` is either an ordinary no-argument function pointer or points to a dynamically allocated block of 16-byte aligned memory. If a specific marker (for example, a `uint32` integer) is written at the beginning of that dynamically allocated memory, then when `_p` is 16-byte aligned, we only need to read the first 4 bytes of the memory pointed to by `_p` to determine the type of the `closure`. Even if `_p` is an ordinary no-argument function pointer and happens to be 16-byte aligned, reading the first 4 bytes of the memory it points to **should** be safe.

This of course goes beyond the scope of the C++ standard. But for performance and a better user experience, coost still adopted this approach. For functions with parameters, the corresponding constructor of `closure` is as follows:

```cpp
template<typename F, typename = std::enable_if_t<
!std::is_convertible_v<std::decay_t<F>, void(*)()>>, typename ... A>
closure(F&& f, A&& ... a) {
struct S {
S(F&& f, A&& ... a)
: _f(std::forward<F>(f)), _a(std::forward<A>(a)...) {
static_assert(offsetof(Header, magic) == 0);
_header.magic = 0xdeadbeef;
_header.off =

offsetof(Header, fp);
_header.fp = [](void* p) {
S* const s = (S*) ((size_t)p & ~(size_t)1);
if (((size_t)p & 1) == 0) {
std::apply(s->_f, s->_a);
} else {
s->~S();
co::free(s, sizeof(S));
}
};
}

~S() = default;

struct Header {
uint32 magic;
uint32 off;
void (*fp)(void*);
} _header;
std::decay_t<F> _f;
std::tuple<std::decay_t<A>...> _a;
};

_p = co::alloc(sizeof(S), alignof(S));
runtime_assert(_p);
new (_p) S(std::forward<F>(f), std::forward<A>(a)...);
}
```

Key points:

- The `!std::is_convertible_v` in the template parameters ensures that simple lambda expressions such as `[](){...}` match the constructor for ordinary no-argument functions;
- `_header.magic` is always set to `0xdeadbeef`, which is used to distinguish the type of `closure`;
- `_header.fp` is the type-erased function pointer, and its parameter `p` is the `_p` in `closure`. Here, a tagged-pointer trick is used to distinguish between "calling the function" and "destroying the closure object", thereby eliminating the need for an additional function pointer to store the destructor and saving memory.

The implementation of `operator()` is as follows:

```cpp
void operator()() {
void* const p = _p;
if (p) {
if (((size_t)p & 15) != 0 || *(uint32*)p != 0xdeadbeef) {
((_F)p)();
} else {
(*(_FP*)((char*)p + ((uint32*)p)[1]))(p);
}
}
}
```

- If `_p` is not 16-byte aligned, or the first 4 bytes of the memory pointed to by `_p` are not `0xdeadbeef`, then `_p` is cast to an ordinary no-argument function pointer and executed directly;
- Otherwise, the `_header.fp` described in the previous code is obtained according to the memory layout and executed.

An example usage of `closure` is as follows:

```cpp
#include "co/print.h"
#include "co/closure.h"

void f() {
co::println("f()");
}

int main(int argc, char** argv) {
co::closure c(f);
c();

co::closure d([]() {
co::println("[]() {}");
});
d();

co::closure e([](int v) {
co::println("e called: ", v);
}, 8);
e();

return 0;
}
```

The complete code implementation can be found in [co/closure.h](https://github.com/idealvin/coost/blob/master/include/co/closure.h). The code in this article is for research and reference only. Discussion is welcome.

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

Do you legitimately believe in 5 years your knowledge of C++ will be worth anything ?

Can we please stop beating around the bush and acting like language design is a thing that even matters at this point?

Most senior engineers at respected companies are using agents to code. The ergonomics of programming has largely been designed around human usage. But we are moving into a world, where people aren't going to be directly coding for the most part -- if at all. In fact, for many people they are already at that point RIGHT NOW. Can we just be honest with ourselves that the constructs we have created for forwarding this language were all designed in the pre-AI era, and now that we have sufficiently powerful enough AI we really need to dig deep and be honest if any of this makes sense anymore.

I have worked as a professional C++ programmer for almost 20 years and I can see the obviousness of this daily. However people on this particular subreddit are acting as if their little article on this language even matters. What is wrong with you people? Have some self respect and just be honest about where we are at in the technological timeline.

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

Show r/cpp QtIndustrialWidgets: A modern C++17 instrumentation widget suite for Qt 6 with pixel-level tests and benchmarks

Hi everyone,

I'd like to share QtIndustrialWidgets, an open-source (MIT) C++17 library providing 12 specialized instrumentation, DAQ, and SCADA widgets for Qt 6 (QtWidgets).

🔗 GitHub Repo: https://github.com/paolosereno/QtIndustrialWidgets
📖 Documentation: https://paolosereno.github.io/QtIndustrialWidgets/

# Why this project?

In aerospace, automotive testing, and industrial automation, C++ with QtWidgets remains the standard for low-latency desktop control software. However, existing open-source widget collections are often either legacy tools, unmaintained snippets, or pull in unnecessary external dependencies.

I built this library with three core technical principles:

1. Zero third-party dependencies: Strictly self-contained, linking only against standard Qt Core, Gui, and Widgets.
2. Predictable rendering performance: Dial backings, scales, and graduation ticks are pre-rendered into cached QPixmap backings, allowing needle rotations and live strip chart updates to run at high refresh rates without burning CPU cycles during high-frequency data ingestion.
3. Rigorous Quality Assurance:
Multi-platform CI across Linux (GCC), Windows (MSVC), and macOS (Apple Clang).
Pixel-level rendering tests with deliberate sabotage checks (verifying that tests fail when layout/rendering logic is broken before merging).
Fully REUSE-compliant licensing and automated SPDX SBOM generation on releases.
Documented benchmarks with reproducible methodologies.

# What's included (12 widgets):

Analog & Gauges: `RadialGauge` (circular/semicircular dials), `LinearGauge` (column & thermometer mode), `CircularBargraph`, `Compass` (heading card with bug).
Controls & Switches: IndustrialKnob (continuous & stepped rotary with CNC knurling), IndustrialSwitch (toggle, rocker, and guarded safety switch).
Displays & Indicators: `SevenSegmentDisplay` (scalable vector LED/LCD), `LedIndicator`, `LevelMeter` (stereo dB with peak hold).
Charts & Monitoring: StripChart (real-time rolling telemetry with NaN dropout handling), AnalysisChart (offline data review with multi-rate support), AnnunciatorPanel (ISA-18.1 industrial alarm tiles).

It also ships with a separate Qt Designer plugin for drag-and-drop WYSIWYG workflow, CMake FetchContent support, Conan 2 recipes, and Debian .deb packages.

# 🚧 Active Development & Building with AI

The library is under active development.

As part of the development workflow, I am building the library with the assistance of AI acting as an architectural and coding pair-programmer. The entire codebase is backed by strict human architectural direction, thorough code review, and verified by automated test suite and pixel-level sabotage checks.

The repository includes an interactive Gallery application to test all widgets and themes live.

I’d love to hear your thoughts, critique on the C++ design, and suggestions for additional industrial components you'd like to see!

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