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 exceptionally challenging because it can cause death or severe injury to the patient and the operator.

I have a question 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 using auto, initializing with curly braces, preferring tasks over threads, or don’t touch memory. I more and more teach them and incorporate into 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 rules. 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? These are only 19 rules. The last one is still missing.

I’m not too fond of the idea that each trainer will develop rules. In a good case, the work is redundant. In the wrong 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. 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. Consider contract-based programming, reflection, or more functional and mathematical concepts in modern C++. That is not all. Concepts will revolutionize templates.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

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

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

In the end, I have a vital concern. In embedded software development, you often have to stick to MISRA C++. The Motor Industry Software Reliability Association published the current MISRA C++:2008 guidelines. They are based on the MISRA C guidelines from the year 1998. Initially designed for the automotive industry, they became the de facto standard for implementing 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 conceptual problem. We have to follow a C++ standard that is from 2008. To say it differently, guidelines are not 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 the 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 must overload the arithmetic and literal operators for the suffixes. Here are the details of user-defined literals.

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

My hope

I hope that the C++ Core Guidelines 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 be 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.

Post Views: 5,397

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS