Skip to content
Hallway
0:00 / 0:00

#c++#facebook#shared_ptr

CppCon 2017: Louis Brandy “Curiously Recurring C++ Bugs at Facebook”

CppCon

189K subscribers • 94 videos on Hallway • Conference channel

YouTube
  • Recommended by 5 people: 4 on Hacker News and 1 curated list.
  • A classic. People kept recommending it from 2020 to 2025.
  • Presented by Louis Brandy, Director of Engineering at Facebook
  • Linked in the descriptionCppCon/CppCon2017

Intermediate. Assumes working knowledge.

158K views9 years ago5 recommendations

Programming languagesSystems programmingC++Performance and optimizationConcurrency and parallelism

Louis Brandy shares common, subtle, and recurring C++ bugs found in Facebook's massive codebase, explaining why they happen and how to avoid them.

CppCon.org — Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2017 — I've spent the last few years watching Facebook's C++ codebase grow by several orders of magnitude. Despite constantly improving abstractions, constantly improving tooling, frequent internal courses, and ongoing internal discussion, there are bug-patterns we simply cannot stop from being reintroduced into our code. My hope is to show some of the most common (and infamous) bugs in our history, and the surprising complexity that arises in some apparently simple situations. This talk serves the dual purpose of educating the intermediate (and perhaps the occasional advanced) C++ programmer about some really nasty common pitfalls, as well as serves as a plea to experts to help further improve the language, libraries, and best practices to help educate and eradicate some of these problematic patterns. — Louis Brandy: Engineering Director, Facebook My team is responsible for the overall health of the Facebook C++ codebase, both the tools and the libraries. We work on: compilers, static/dynamic analysis, linters, large scale changes, and the core libraries. — Videos Filmed & Edited by Bash Films: BashFilms.com Work at Hudson River Trading (HRT): tinyurl.com/safxfctf --- Videos Filmed & Edited by Bash Films: BashFilms.com

Why it's here

5 people recommend this

What people say. Highly recommended for C++ developers to understand common, dangerous footguns like shared_ptr data races and operator pitfalls.

wyldfireon Hacker News • Recommends

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 link to this video 2 link
View on Hacker News

programming-talkscurated list on GitHubRecommends

Under “C++”

Curiously Recurring C++ Bugs at Facebook 00:52:00 by **Louis Brandy** (2017)
View the list

slavik81on Hacker News • Recommends

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: link to this video
View on Hacker News

oconnor663on Hacker News • Recommends

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: link to 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.
View on Hacker News

ddulaneyon Hacker News • Recommends

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: link to this video
View on Hacker News

u/syklemilconsidered harmfulin r/ProgrammingLanguages • Mentions

On “Types on the left or right?”

> C++ is especially terrible, it's grammar is not even context-sensitive and even a small typo can lead to wildly different parsing rules (see `a<b>::c(d)`, which is terribly ambiguous and confusing) There's a bit in CppCon 2017: Louis Brandy on “Curiously Recurring C++ Bugs at Facebook” that goes into this, and the rule in C++ that "if it could be interpreted as a declaration, it _is_ a declaration", which leads to people thinking that they've acquired a (mutex) lock, but what they've actually done is declare a new mutex through unexpected syntax. Possible to lint, hard to debug.
4View on Reddit

dureuillon Hacker News • Mentions

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: link to this video
View on Hacker News