I this post I give an introduction to the rules for generic programming in C++. Generic programming is, from my point of view, the outstanding feature and the future of C++. Hence it follows that this and the upcoming posts are about the future of C++.

Making objects or methods const has two benefits. First, the compiler will complain when you break the contract. Second, you tell the user of the interface that the function will not modify the arguments.

If you can't throw an exception and can't use final_action (finally) from the guideline support library, you have a problem. Exceptional states require exceptional actions: goto. Really?

To make my point clear, this post is about the exceptional case that you can not throw an exception. If your program runs in a restricted embedded environment or you have to fulfil a hard-real-time requirement, this situation may be not so exceptional to you.

Today's post is about the right way to throw and catch exceptions. This means when you should throw and how you should catch an exception.

If you skim the remaining rules to error handling, you often read the word noexcept. Before I write about the rules for error handling, I will write about the noexcept specifier and the noexcept operator in this post. 

My original plan was it to write in this post about the next rules to error handling. But I changed my plan to write about the future: contracts in C++20.

Error handling is an essential part of writing good software; therefore, the C++ core guidelines have about 20 rules for error handling.

Today, I will finish my story on concurrency and lock-free programming. There are four rules to lock-free programming in the C++ core guidelines left.

Today, I will solve the riddle from my last post. Thanks to my readers, the analysis of the ABA problem is quite accurate.