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

What people said

wyldfire · 2020-01 · Strong recommendation

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] [VIDEO] [2] [LINK]

Read the original HN comment ↗

ddulaney · 2025-04 · Recommendation

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]: [VIDEO]

Read the original HN comment ↗

oconnor663 · 2023-01 · Recommendation

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: [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.

Read the original HN comment ↗