Preface

This book is not written to impress you. It is written to be useful.

I have watched the same pattern repeat many times: a capable programmer — someone who already thinks clearly about hard problems — sits down to learn C++ and gets stuck. Not because the ideas are impossibly difficult, but because the available explanations are either too shallow ("C++ is just like Python but faster!") or they immediately dive into undefined behavior, the memory model, and template metaprogramming before anyone has written a single working program. The shallow ones leave you stranded the moment anything real goes wrong. The deep ones lose you before you get anywhere.

This book tries to be neither.

Why "Boring"?

The name is deliberate. Boring means predictable. Boring means you know what is on the next page. Boring means complete programs instead of fragments, repeated explanations rather than vague callbacks to sections you read three chapters ago, and honest assessments of difficulty instead of cheerful promises that "C++ is easy once you know the tricks."

There are no tricks in this book. There are patterns — patterns you will see in every chapter, with small variations, until they stop being things you look up and start being things you just do. That is what boring means here.

How this book came to be

A colleague of mine — Leila, a physicist who had spent years writing Python simulations — needed to speed up the inner loop of a particle collision model by about twenty times. Python, even with NumPy, was not going to get there. She decided to learn C++.

She read three tutorials. The first one told her that C++ was "basically Python with explicit types" and showed her Hello World with printf. The second one threw her immediately into raw pointers, memory layout, and the difference between stack and heap allocation, without ever showing her a complete program that did something useful. The third one was so in love with template metaprogramming that it introduced std::enable_if before it introduced for loops.

Leila came to me on a Tuesday afternoon, frustrated and confused. We sat together until the evening. By the time we finished, she had a working particle simulation in C++ that ran faster than her Python version by a factor of thirty-five. The notes I wrote for her on a notepad that afternoon became the first draft of what is now Chapter 6 of this book.

The notes grew. Others asked for copies. By the time I had twelve chapters and five appendices, it seemed worth publishing properly. Boring College agreed to publish it, which felt exactly right.

About the code

Every code listing in this book is complete. You can copy it, compile it with the command shown, and run it exactly as written. Nothing depends on code defined in a different file unless I tell you explicitly what that file contains and where to find it.

All code is available on GitHub so you do not have to type everything by hand:
<TODO: book code repository URL>

The code uses C++17 as its baseline — the standard that has been supported by all major compilers since around 2017 and is safe to use in virtually any environment you are likely to encounter. Where I use C++20 or C++23 features (Concepts, std::format, std::expected), I say so clearly and explain what compiler version you need.

About me

I am Dariush Abbasi — a C++ developer who has spent the last decade writing performance-critical software: scientific simulations, systems tools, data pipelines. I maintain open source projects and write at github.com/dariubs. Boring C++ is my second book; the first was Boring CUDA, which taught GPU programming using the same approach.

I am not a language lawyer. I did not write a compiler. I learned C++ the same way you are about to: by compiling things, reading error messages, fixing them, and running the result. That experience is in every page of this book.

How to read it

Start at Chapter 1. The book is designed to be read in order — each chapter assumes you understood the previous one.

If you already know C or Java, you will find Chapters 3 and 4 move quickly. If you have written Python for years, Chapter 3 will feel a bit strange in places — the type system is more explicit, the conversions are less forgiving. Slow down there.

Chapter 6 — memory, ownership, and lifetime — is where most people slow down. This is expected and normal. Do not skip it. Everything in Chapters 7 through 12 depends on understanding what you are responsible for managing and what the language manages for you. Read Chapter 6 twice if you need to. Work through the exercises.

A note on repetition

You will notice that I repeat things. The same patterns — RAII, const-first, smart pointers before raw pointers — appear in every chapter. That is intentional.

In programming, repetition with small variations is how knowledge becomes instinct. If you see the same five-line pattern in Chapter 5, Chapter 7, and Chapter 12, you will not need to look it up in Chapter 12. You will simply write it. That is the goal.

— Dariush Abbasi
May 2026