Why do we need Guidelines for Modern C++?

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 extremely challenging because it can cause death or serious injury for the patient and the operator.

I have a question in mind that we should answer as a C++ community.

Why do we need guidelines for modern C++?

Here are my thoughts. I'm only concentrating on three facts. Of course, there are more than three. This three represent my personal opinion.

C++ is inherently complicated for the novice

C++ is in particular for beginners an inherently complicated language. When you teach people C++, you should provide a set of rules that work for them in at least 90% of all use-cases. I think about rules such as use auto, initialize with curly braces, prefer tasks over threads, or don't touch memory.  I more and more teach them and incorporate them in my training. Therefore, we need a canon of best practices in C++. They state how you should write code.

I'm actively searching for these rues. Therefore, I gave a few presentations including 10 tips on how to write modern C++. Currently, I write a ten-part series for the German Linux Magazine about tips. I used as a starting point the Zen of Python, by Tim Peters: These are 20 aphorisms of how to write code in Python.

These are 20 rules for writing idiomatic code in Python. Twenty, really? Actually, these are only 19 rules. The last one is still missing.

I don't like the idea that each trainer will develop their own set of rules. In a good case, the work is redundant. In the bad case, we teach different or maybe contradicting rules.

C++ becomes more and more challenging for the professional programmer

I'm not so concerned about the sheer amount of new features, we get with each new C++ standard. I'm more concerned about the new concepts modern C++ supports. To be honest, these are the most challenging topics for the professional C++ programmer. You have to rethink and maybe change the way you solve problems. Think about event-driven programming with coroutines, lazy evaluation, infinite data structures, function composition, or range comprehensions with the ranges library. Think about contract-based programming, reflection, or more and more functional and mathematical concepts in modern C++. That is not all. Concepts will revolutionise templates.

I stated that this plethora of new concepts will, in particular, overwhelm the professional programmer. He is the one who is used to solve problems with his classical tools. He will fall with high probability in the hammer-nail trap.

C++ is very often used in safety-critical systems

At the end, I have a strong concern. In the embedded software development you have often to stick to MISRA C++. The current MISRA C++:2008 guidelines were published by the Motor Industry Software Reliability Association. They are based on the MISRA C guidelines from the year 1998. Originally designed for the automotive industry they became the de facto standard for the implementation of safety-critical software in the aviation, military and medical sector. As MISRA C, MISRA C++ describes guidelines for a safe subset of C++. If you don't know MISRA C++, here are more details: Facts. 

There is a conceptional problem. We have to follow a C++ standard that is from 2008. To say it differently that guidelines are not the state of the art for modern software development in C++. It's three standards (including C++17) behind.

I want to provide an example: MISRA C++ doesn't allow operator overloading. That is not a state of art of writing C++. I teach in my seminars literal operators for implementing type-safe arithmetic such as: auto constexpr dist = 4 * 5_m + 10_cm - 3_dm. To implement such type-safe arithmetic, you have to overload the arithmetic operators and the literal operators for the suffixes. Here are the details of user-defined literals.

To be honest. I don't believe that MISRA C++ will ever come in lockstep with the current C++ standard. My hope is a different one.

My hope

My hope is that the C++ Core Guidelines that I introduced in the post "What is Modern C++" become the guidelines for Modern C++. That means in particular that the C++ Core Guidelines will replace in the long run MISRA C++ as the obligatory standard for C++ in safety-critical systems.

Of course, that was an extremely subjective post. What are your thoughts? I'm curious about your comments.

What's next?

The rules of the C++ Core Guidelines are not intended to read as a book. They are intended to be the target for tools. But before using a tool, I want to know the details. Therefore, I will present the rules of the C++ Core Guidelines in my next posts.

Thanks a lot to my Patreon Supporter: Eric Pederson.