Hi C++ friends 👋 Today we continue exploring one of the most exciting features coming with C++26: static #reflection. In previous posts, we looked at how reflection can help us build “magic enum” style utilities, and even how we can generate aggregate-like structures from text at compile time. This time, let’s look at something much more practical. And much more painful. Reading configuration from command-line parameters. And by “painful,” I mean the #boilerplate kind. 🙂 Th

Hi C++ friends 👋 Today we are going to explore another feature from the future of C++. Or maybe not exactly the future anymore. C++26 is getting closer, compilers are slowly catching up, and some of the things we used to describe as “maybe one day” are starting to become real tools we can experiment with today. One of those tools is #embed. And when we combine it with C++ reflection, things become very interesting. Not “interesting” like undefined behavior interesting. Hopef

Modern C++ gives us incredibly powerful tools, and Polymorphic Memory Resources (PMR) is one of the most exciting additions from C++17. Custom allocators, memory pools, stack-backed buffers it all sounds like a guaranteed performance win. But as always in performance engineering…👉 it depends. In this post, I ran a simple benchmark to answer a practical question: Does using PMR with std::vector and std::string actually make things faster? The answer is surprisingly nuanced a

I had to delete my previous post because the benchmark lied to me. That is already a very C++ way to start a day. The topic sounded simple enough: compare push_back() and emplace_back() for std::vector<std::string>, show the results for C++11 and C++23, and extract a nice practical lesson. Simple, right? Well, not quite. At first, I used older compilers on Quick-Bench and got results that looked strange. Strange enough that after double-checking, I realized I had stepped on a

How One Line of C++ Caused a Segmentation Fault Coroutines are one of the most exciting additions to modern C++. They promise cleaner async code, better readability, and fewer callback pyramids. But they also come with something very C++-like: 👉 lifetime rules you must understand In this post, we’ll look at a tiny coroutine that looks perfectly safe and still crashes with a segmentation fault. The Innocent Code Let’s start with a minimal example: #include <coroutine> #incl

Coroutines are powerful.They make asynchronous code readable, composable, and expressive.But they are also merciless when it comes to lifetime mistakes. In this post, I want to walk through a real bug that looks completely harmless at first glance — modern C++, clean abstractions, universal references — and still ends up as a data-integrity time bomb . This is not a coroutine bug.This is a fundamentals bug , made visible by coroutines. The Setup: Everything Looks Fine Imagi

When we talk about modern C++, it’s easy to focus on advanced topics: coroutines, async frameworks, schedulers, and performance tuning.But time and again, real production bugs come from something much simpler. Fundamentals. In this post, I want to show how a single line that looks completely reasonable can introduce a use-after-free bug in coroutine-based code and why understanding ownership and lifetimes is more important than ever in modern C++. The Code Consider the foll

or decades, developers have debated the performance differences between C and C++ . You've probably heard it all before: “C is faster...