Herb Sutter

> I don't have enough time to watch these kinds of presentations.

Then let me pick and share some of my favorites that I found enlightening, and summarize with some information that I found useful.

By far, the most useful one is Khalil Estell's presentation last year [0]. It's a fairly face paced but relatively deep dive into exception mechanics. At the end, he advocates for a new tool that would audit a program to determine what exceptions could be thrown. I think that's a flipping fantastic idea for a tool. Unfortunately I haven't seen any progress toward it -- if someone here knows where his tool is, or a similar tool, please reply! I did send him an email a few months ago inquiring about it, but haven't received a reply. Nonetheless, the whole presentation was excellent in my opinion. I did see that he had another related presentation at ACCU this year [4] with a topic of "C++ Exceptions are Code Compression" (which I totally can believe -- I've seen it myself in binary sizes), but I haven't seen his presentation yet. I'll watch it later today.

Just about anything from Herb Sutter is good. I don't like that he works for Microsoft, but he does great stuff for C++, including the old Guru of the Week series [1]. In particular, his 2019 presentation [2] describes different error handling techniques, some difficulties and pitfalls in combining libraries with different error handling techniques, and leads up to explaining why std::expected came about. He does pontificate a…

Contention is not binary, or, rather, its effects aren't binary. A lock that is held for 10 microseconds potentially causes a lot more contention than a CAS that takes a few nanos. OTOH, thousands of short contentions are as bad as, or worse, than few long contentions (there's a whole great talk by Doug Lea about how Java's fork/join tricks modern CPU out of crazy power-saving optimizations to reduce thread wakeup time).

Intel's TBB were modeled after java.util.concurrent, BTW. Later, the Java memory model inspired the C++11 memory model (and the Java people were called to help with that, too). When it comes to concurrency, Java is usually at least 5 years ahead of C++ (perhaps with the exception of fork/join, which was inspired by Cilk, but has since come to surpass it).

> I'm not sure what is so hard about Hazard Pointers

Hazard pointers are expensive without RCU (the hazards need to be visible to other threads, which means store-load barriers), and RCU requires kernel cooperation, and besides this entire class of techniques is either very limited or incredibly complicated (what do you do if you have thousands of threads?). A good GC vs hazard pointers with or without RCU is like driving down a highway vs stumbling in a swamp when it comes to lock-free data structures.

Here's Herb Sutter on the issue (source: http://herbsutter.com/2011/10/25/garbage-collection-synopsis-and-c/):

All existing C++ garbage collectors, notably the Boehm collector, aren’t enough for many…

When the STL became part of the standard library ( http://www.stlport.org/resources/StepanovUSA.html ), there was a question of how to handle algorithms that sort containers, or that perform a binary search, or in some other way, need to know whether “a” is less-than, equal-to, or greater-than “b”. The algorithms have to work on primitive types, and user defined types as efficiently as possible. They eventually decided to only require a function for “less-than.” And if “a < b” returns false, and “b < a” also returns false, then “a” and “b” are considered equal.

There are times that doesn’t work, so documentation usually has a footnote that (1) certain algorithms require a partial ordering and not necessarily a total ordering, and (2) to use those algorithms, you must implement less-than, but any other comparison operator is ignored by the algorithm; instead, less-than is used to figure out greater-than and equal-to as needed. This was considered better than requiring programmers to implement a collection of comparison operators, and trusting those programmers to make those operators act consistently with each other (e.g., never say that “a” and “b” are both less-than and greater-than each other).

The spaceship operator seems to address this specific case ( https://open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r0.pdf ). According to Herb Sutter (note that his name is on the proposal), “We added the C++20 spaceship operator to the language, but we also applied it…

I think TiKV is a good example where team chose Rust over Modern C++. Rust gives the same performance and is close to metal like C when it is necessary. All possible memory management mistakes it catches at compile time if it's not "unsafe" and this is a really great!

With Rust I can hack without fear! I shouldn't remember tons of C++ rules which are described in http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines, "C++ programming language" book, also here https://herbsutter.com/gotw/, etc and I can focus on algorithms and implementation.

C++ combines a lot of different paradigms m.b. more correct I would like to say "C++ paradigms hell"! Which of C++ subsets is the right way, no one understands. Even Bjarne Stroustrup said, "Within C++, there is a much smaller and cleaner language struggling to get out." - and where is this "smaller and cleaner language"?. What is the idiomatic style in C++? Is it Google guidelines, CoreCpp guidelines or other enormous guides?

I look inside a lot of C++ projects and each of them has different styles, use different paradigms, sometimes look like different languages!

Rust, Go, C, Java code bases look the same, they have their own idiomatic style, their own way.

I think Rust is the next step in the evolution of system programming language.

"Coroutines (Gor Nishanov) was adopted for C++20. A number of other authors that have their own coroutine proposals have also done great work to give feedback to this design and inform the committee in the process of showing their own designs, and the adopted coroutines design is expected to adopt some of their additional programming capabilities in the future as well as we continue to build on it after C++20. At this meeting, we had many detailed design discussions, including notably these papers that will be available in a few weeks when the post-meeting mailing is posted: a unified consensus report from all coroutines proposers describing the strengths and weaknesses of all their proposals, and a consensus report from implementers from all major C++ compilers about the tradeoffs and feasibility of the basic facilities required by the various coroutines proposals. Both of these papers are very educational and highly recommended."

https://herbsutter.com/2019/02/23/trip-report-winter-iso-c-standards-meeting-kona/

The papers aren't available yet but presumably will explain the reasoning behind accepting them in their current form.

There is this guideline of "Almost Always Auto" (https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/) and I have been following it for yeears both in my job and my personal projects and I have never been very confused by it or had any sort of bug because of it. I felt very reluctant about using it at all for quite a while myself, but in practice it just makes stuff easier and more obvious. A huge reason it's useful in C++ is generic code (stuff that depends on template parameters or has many template parameters) or deeply nested stuff (typing std::unordered_map<std::string, MyGreatObject::SomeValue>::iterator gets annoying), but it's nice almost everywhere.
Most types are repeated and getting rid of those repetitions makes refactorings a lot easier and gets rid of some source of bugs. For example sometimes you forget to change all the relevant types from uint32_t to uint64_t when refactoring some value and stuff breaks weirdly (of course your compiler should warn on narrowing conversions, but just to illustrate the point, because it is very real).