A class is a user-defined type where the programmer can specify the representation, the operations, and the interface. The C++ core guidelines have a lot of rules for user-defined types.

Today,  I conclude my treatise about the rules for functions in the C++ core guidelines. The last post was about the syntax of function parameters and return values. This post, with its roughly 15 rules, is about their semantics.

You have many choices to pass function parameters. You can pass by value or by reference. A reference can be const or non-const. You can even move or forward your parameters.  Your decision should depend on if it is an in, and out, an in-out, a consume, or a forward function parameter. Curious? Read the post!

Functions are the "fundamental building block of programs."  and "the most critical part in most interfaces."  These statements introduce the rules to function of the C++ core guidelines. Of course, both statements are right. So, let's dive deeper into the more than 30 rules for defining functions, passing arguments to functions, and returning values from functions.

The guidelines support library (GSL) is a small library for supporting the guidelines of the C++ core guidelines. It should help to write better C++ programs. Therefore, its key concerns are memory safety and type safety. They are already a few implementations of the GSL available.

Interfaces are a contract between a service provider and a service consumer. The C++ Core Guidelines have 20 rules to make them suitable because "interfaces is probably the most important single aspect of code organization".

Interfaces are a contract between a service provider and a service consumer. The C++ Core Guidelines has 20 rules to make them suitable because "interfaces is probably the most important single aspect of code organization".

Today, I will dig deeper into the C++ Core Guidelines. I wrote about the Introduction section in my last post about the C++ Core Guidelines. Today I write about the section that is "primarily for humans". This is the most general section and is called Philosophy. The rules are so general that you can apply them to each programming language.

This subjective post is based on more than 15 years of experience as a trainer for C++, Python, and software development in general. In the last years, I was responsible for the software and the team for building software for defibrillators. That included the regulatory affairs for our devices. Writing software for a defibrillator is exceptionally challenging because it can cause death or severe injury to the patient and the operator.

We often speak about classical and modern C++. What does that mean? First of all: What is modern C++? There is a simple and a not-so-simple answer. The simple answer is. Modern C++ stands for C++, which is based on C++11, C++14, and C++17. I guess you know it. This post and a series of further posts are about the not-so-simple answer.