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

- 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" - ▶ this 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]

in “Ask HN: Best way to learn modern C++?” · View on HN

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] ▶ this video [2] [link]

in “Ask HN: How to refresh on modern features of C++?” · View on HN

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: ▶ this 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

in “Things you can’t do in Rust (and what to do instead)” · View on HN

In our 60+ team of C++ programmers, a constant theme that keeps coming up in code reviews is how a function optimally takes its parameters. There's been enough overthinking and I came across Herb Sutter's CppCon 2014 Essentials of Modern C++ Style [1] where he explains the various cases. I made a cheat sheet (1-page PDF) for quick reference of the options and when to go for them. Comments and suggestions welcome! GitHub project [2]. # Credits - Herb Sutter, other C++ experts and the community - Emacs[3] and Org-mode[4] creators - CheatSheet by Musa Al-hassy # Links [1]: ▶ this video [2]: [link] [3]: [link] [4]: [link] [5]: [link]

in “Cheat Sheet: C++ Function Parameter Choices [pdf]” · View on HN