CppCon 2014: Herb Sutter "Back to the Basics! Essentials of Modern C++ Style"

What people said

pjmlp · 2018-03 · Recommendation

- Tour of C++ ( [LINK] ) - Principles and Practice Using C++ ( [LINK] ) - From Mathematics to Generic Programming ( [LINK] ) - The Scott Meyers books Some of the Bjarne Stroustrup videos, "Learning and Teaching Modern C++" - [LINK] Some of the Herb Sutter videos, "Writing Good C++14... By Default" - [LINK] "Back to the Basics! Essentials of Modern C++ Style" - [VIDEO] Some of the Kate Gregory videos, "Stop Teaching C" - [LINK] "10 Core Guidelines You Need to Start Using Now" - [LINK] "It's Complicated" - [LINK]

Read the original HN comment ↗

jerv · 2014-12 · Recommendation

Herb Sutter, one of the most prolific C++ experts out there, recently gave a talk on Modern C++ [1]. In the beginning of his talk, he states that every C++ developer should read a "Tour of C++" [2] by Bjarne Stroustrup, the original designer of C++. I recently read it and it's great. The book has less than 200p, but still covers the most important parts of C++11, albeit not in great detail (the reader is pointed to "The C++ Programming Language" by the same author for that). Read it! And watch the youtube video in [1]. [1] [VIDEO] [2] [LINK]

Read the original HN comment ↗

oconnor663 · 2021-05 · Reference

ASan, UBSan, etc. are absolutely life-changing, no doubt about it. But there's a pretty big difference between catching things statically, and catching them at runtime. If you have an issue that, say, only triggers on odd-numbered Tuesdays on Windows 7, your tests suite is probably going to miss it, and ASan isn't going to be able to help you. Here's an example from one of Herb Sutter's talks, which I refer to frequently. He describes an issue that can come up with shared_ptr in reentrant/callbacky code, and the punchline is that you have to be careful never to dereference a shared_ptr that might be aliased: [VIDEO] I also just wrote a giant example of my own :) in reply to your toplevel comment. [LINK] . TSan will be pretty good at catching some of the simple variants of this, like where you totally forget to take a lock. But it's going to have a hard time with cases where you "stash" a reference longer than you should, because later uses of the reference might appear safe for a while yet become unsafe down the road with unrelated code or timing changes. Another issue with ASan and UBSan, is that every application has to run them (and maintain its own test suite comprehensive enough to make them useful). With static checks, a memory-safe library is memory-safe for everyone , even for applications that aren't particularly careful with their tests. The library author is able to express their safety requirements through the language, and all callers have to respect those requir

Read the original HN comment ↗