CppCon 2017: Louis Brandy “Curiously Recurring C++ Bugs at Facebook”
Why Hacker News recommends it
HN recommends it as a must-watch catalogue of C++ footguns, often cited in debates about Rust and C++ safety.
What it is
Louis Brandy presents the most common and infamous recurring C++ bugs seen in Facebook's huge codebase, including shared_ptr data races and operator[] pitfalls. He explains the surprising complexity behind seemingly simple code.
Recommended by 4 HN commenters across 4 different months, 2020 to 2025.
What Hacker News said
Strong rec wyldfire · 2020-01 · on “C++20 Reference Card”
No. Sorry for being unclear. [1] is a great video that covers a lot of good stuff in particular this usability bug. It's worth watching in its entirety. If you don't want to sit through the video, here's the broken code in question: void Obj::update() noexcept { unique_lock<mutex>(m_mutex); do_the_mutation(); } "unique_lock<mutex>(m_mutex);" has no effect, but you might mistakenly think that this will block on m_mutex. Labeling unique_lock's constructor as [[nodiscard]] would force you to think twice. See [2] for more details. [1] [this video] [2] [LINK]
Recommends slavik81 · 2021-06 · on “My favourite C++ footgun”
I'm a big fan of Scott Meyer's Effective C++ . It's a little dated now, but it was the most valuable book I'd ever read on the language. Louis Brandy's Curiously Recurring Bugs at Facebook presentation from CppCon17 has somewhat of the same feeling, though it only covers a few bugs: [this video]
Recommends oconnor663 · 2023-01 · on “Swift Achieved Dynamic Linking Where Rust Couldn't”
There are many differences when it comes to safety: - Like you said, Rust doesn't let you data race on the contents of an Arc. - Rust also doesn't let you data race on the Arc itself (i.e. repointing a global Arc without synchronization). This is Bug #5 in this great talk: [this video] - Rust also doesn't let you retain a reference to the contents of an Arc longer than you retain the Arc. This is the bug that C++ Core Guideline R.37 is about: [LINK] But I'm not sure I'd call these Arc vs shared_ptr differences per se, because almost any comparison between a Rust container and its C++ equivalent looks similar.
Recommends ddulaney · 2025-04 · on “Pitfalls of Safe Rust”
Unfortunately, operator[] on std::vector is inherently unsafe. You can potentially try to ban it (using at() instead), but that has its own problems. There’s a great talk by Louis Brandy called “Curiously Recurring C++ Bugs at Facebook” [0] that covers this really well, along with std::map’s operator[] and some more tricky bugs. An interesting question to ask if you try to watch that talk is: How does Rust design around those bugs, and what trade offs does it make? [0]: [this video]
Cites dureuill · 2024-02 · on “Too dangerous for C++”
The point of the article isn't that single-threaded non-atomic shared pointers are unfeasible in C++, it is that their usage is too dangerous. The fact that it wasn't included in the standard library for this reason is an argument for this. The fact that even `shared_ptr` has thread-safety footguns, one of which made it to the famous C++ talk, “Curiously Recurring C++ Bugs at Facebook”[1], is another. By the way, every single of the bugs from that talk is impossible in safe Rust. [1]: [this video]