The Big C++ Blog

PMR vs std::vector When “More Advanced” Gets Slower

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

push_back() vs emplace_back(): The Benchmark That Made Me Delete a Post

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

A Tiny Coroutine, a Big Crash💥

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

When Coroutines Betray You: A Lambda Lifetime Bug You Don’t See Coming

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

A Tiny C++ Detail That Can Crash Your System

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