4 HN users recommended this talk4 months2020–2025score 4.5
Years with an HN recommendation, 2007–2026
HN recommends it as a must-watch catalogue of C++ footguns, often cited in debates about Rust and C++ safety.
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.
“is a great video that covers a lot of good stuff in particular this usability bug. It's worth watching in its entirety.” (HN, 2020)
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]
Covers many good C++ bugs including a unique_lock usability bug.
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]
Similar feel to Effective C++, covering a few recurring bugs.
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.
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]
Covers vector and map operator[] bugs and other tricky bugs.
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]
Cited for shared_ptr thread-safety footguns; claims all bugs impossible in safe Rust.
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
5 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Read more
Citations, criticism and jokes