Myths of My Blog Readers

I was inquisitive about your C++ myths. In particular, my German readers were quite active. I got a few E-Mails and observed a vivid discussion on Heise Developer.

Let me first conclude the myths of the C++ core guidelines before I write about your myths. Here is the last myth.

NR.7: Don’t: Make all data members `protected`

Protected data makes your program complex and error-prone. If you put protected data into a base class, you can not reason about derived classes in isolation and, therefore, you break encapsulation. You always have to reason about the entire class hierarchy.

This means you have to answer at least these three questions.

Do I have to implement a constructor in a derived class to initialize the protected data?
What is the actual value of the protected data if I use them?
Who will be affected if I modify the protected data?

Answering these questions becomes more and more complicated the deeper your class hierarchy becomes.

If you think about it: protected data is a kind of global data in the scope of the class hierarchy. And you know, a mutable shared state is terrible. It makes, for example, testing and concurrency quite tricky.

Now, I switch to your myths. I write about them in the order I received them.

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.

In C++ written programs need more memory and CPU as in C written programs (Gunter Königsmann)

First of all: thanks to Gunter Königsmann for the classical myth.

Arguing against this myth is tricky and, in general, impossible for the C++ standard library. This is why I make only a few observations at the end of this chapter. First of all, here are the hard facts. The “Technical Report on C++ Performance” helps me a lot.

Technical report on C++ performance

The Working Group WG 21 published in the year 2006 the paper ISO/IEC TR 18015. The title sounds not very interesting, but that document is the ultimate source if you want to get the performance numbers of the C++ features. The document expresses its concerns directly to the point.

to give the reader a model of time and space overheads implied by the use of various C++ language and library features,
to debunk widespread myths about performance problems,
to present techniques for the use of C++ in applications where performance matters, and
to present techniques for implementing C++ Standard language and library facilities to yield efficient code.

With more than 200 pages, the paper’s authors are well-known C++ experts like Dave Abrahams, Howard Hinnand, Dietmar Kühl, Dan Saks, Bill Seymour, Bjarne Stroustrup, and Detlef Vollmann.

The scope of the document is C++ features, their overhead and usage, the creation of efficient libraries in C++, the usage of C++ in embedded systems, and the interfaces in C++ to communicate with the hardware.

C++ features, Overhead, and Usage

The authors use for their analysis three computer architectures with five different compilers. They use compilers with different optimization levels. I will give you only an idea of the results that are pretty remarkable.

Namespaces
- Have no significant overhead in size and performance
Type converting operator
- The C++ casts const_cast, static_cast, and reinterpret_cast differ neither in size nor performance from their C pedant.
- The runtime executed dynamic_cast has some overhead. (Remark: The conversion has no C pendant.).
Inheritance
- Class
  - A class without virtual functions is as big as a struct.
  - A class with virtual functions has the overhead of a pointer and a virtual function table. These are about 2 to 4 bytes.
- Function calls
  - The call of a non-virtual, non-static, and non-inline function is as expensive as the call of a free function.
  - The call of a virtual function is as expensive as a free function with the help of a pointer stored in a table.
  - Virtual functions of a class template can cause overhead in size.
  - The inlining of a function causes significant performance benefits and is close to the performance of a C macro.
- Multiple inheritances
  - It can cause time and space overhead.
  - Virtual base classes have overhead compared to non-virtual base classes.
Run-time type information (RTTI)
- There are about 40 additional bytes for each class necessary.
- The typeid call is relatively slow. That seems to be due to the quality of the implementation.
- The conversion during runtime with dynamic_cast is slow, according to the reports. That should also be due to the quality of the implementation.
Exception handling
- There are two strategies for dealing with exceptions. These are the code and the table strategy. The code strategy must move and manage additional data structures to deal with exceptions. The table strategy has the execution context in a table.
  - The code strategy has a size overhead for the stack and the runtime. The runtime overhead is about 6%. This overhead exists even without the throwing of an exception.
  - The table strategy has neither overhand in program size nor runtime. (Remarks: That statements hold only if no exceptions were thrown.). The table strategy is more challenging to implement.
Templates
- You get for each template instantiation a new class template or function template. Therefore, the naive use of temples can cause code bloat. Modern C++ compilers can massively reduce the number of template instantiations. The usage of partial or full specialization helps to reduce template instantiations.

You can read the details, the exact number, and a few additional topics directly in the report: TR18015.pdf.

Still not convinced? Here is a citation from MISRA C++:

MISRA C++

MISRA C++ (Motor Industry Software Reliability Association) formulates guidelines for software in safety-critical systems. Initially designed for the automotive industry, it became the de facto standard in the aviation, military, and medical sectors. The question is, what MISRA says about C++?

MISRA emphasizes why the importance of C++ in critical systems becomes more important. (1.1 The use of C++ in critical systems):

C++ gives good support for high-speed, low-level, input/output operations, which are essential to many embedded systems.
The increased complexity of applications makes the use of a high-level language more appropriate than assembly language.
C++ compilers generate code with similar size and RAM requirements to those of C.

But one slight downer remains. MISRA C++ is based on classical C++. This is simply speaking C++98. Modern C++ has a lot more to offer for embedded systems. This remark holds not only for MISRA C++ but also for the previously mentioned Technical report on C++ performance.

I can not conclude my post without a few observations of modern C++. Modern C++ is primarily used for the three C++ standards C++11, C++14, and C++17.

My Observations

The difficulty in the comparison of the C++ standard library to its C pendants is, in particular, that you have to compare equivalent data structures or programs. This means you can not compare a C-string and a C++ string because the latter supports automatic memory management. The same holds for a C-array in contrast to the C++ containers. Without further ado, here are my points. If you are more curious, read the mentioned post.

A std::array is per design as fast and as cheap as a C-array and additionally knows its length: C++ Core Guidelines: std::array and std::vector are your Friends.
A std::unique_ptr is, per design, as fast and as cheap as a raw pointer. Of course, the std::unique_ptr is safe per design: Memory and Performance Overhead of Smart Pointers.
The type-traits library allows it to write code that optimizes itself: Type-Traits: Performance matters.
With constexpr, you can perform expensive compute jobs at compile-time: C++ Core Guidelines: Programming at Compile Time with constexpr.
Move-semantic and perfect forwarding allows you to replace an expensive and insecure copy operation with a cheap and secure move operation. Generally, a copy operation can fail instead of a move operation: Copy versus Move Semantic: A few Numbers and Perfect Forwarding.

What’s next?

Wow? Arguing against the memory and performance myth took almost an entire post. You can imagine that I have to demystify additional myths which I got. If you have a myth, it’s time to send it to me: rainer.grimm@modernescpp.de.

Post Views: 3,387

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