C++ Core Guidelines: More about Control Structures
My last German post C++ Core Guidelines: To Switch or not to Switch, that is the Question got a lot of attention. To use a hash table instead of a switch statement seems to be a highly emotional topic. So I change my original plan. Today, I will present different kinds of control structures. I will start with the if and switch statements, continue with the hash table, and end with dynamic and static polymorphism. Additionally, I will mark a few remarks about performance and maintainability.
The classical control structure is the if statement; this is my starting point.
if statement
Here is the simple program that I will implement with different control structures.
// dispatchIf.cpp #include <chrono> #include <iostream> enum class MessageSeverity{ // (2) information, warning, fatal, }; auto start = std::chrono::steady_clock::now(); // (4) void writeElapsedTime(){ auto now = std::chrono::steady_clock::now(); // (5) std::chrono::duration<double> diff = now - start; std::cerr << diff.count() << " sec. elapsed: "; } void writeInformation(){ std::cerr << "information" << std::endl; } void writeWarning(){ std::cerr << "warning" << std::endl; } void writeUnexpected(){ std::cerr << "unexpected" << std::endl; } void writeMessage(MessageSeverity messServer){ // (1) writeElapsedTime(); // (3) if (MessageSeverity::information == messServer){ writeInformation(); } else if (MessageSeverity::warning == messServer){ writeWarning(); } else{ writeUnexpected(); } } int main(){ std::cout << std::endl; writeMessage(MessageSeverity::information); writeMessage(MessageSeverity::warning); writeMessage(MessageSeverity::fatal); std::cout << std::endl; }
The function writeMessage in line (1) displays the elapsed time in seconds (3) since the program’s start and a log message. It uses an enumeration (2) for the message severity. I use the start time (4) and the actual time (5) to calculate the elapsed time. As the name suggested, the std::steady_clock cannot be adjusted; therefore, it is the right choice for this measurement. The key part of the program is part of the function writeMessage (1), in which I decide which message should be displayed. In this case, I used if-else statements.
To make it right, I had to look up the syntax for the if-else statement.
Here is the output of the program:
Modernes C++ Mentoring
Do you want to stay informed: Subscribe.
I will skip the output for the remaining examples. Besides the numbers, it is always the same.
switch statement
The following program is quite similar to the previous one. Only the implementation of the function writeMessage changed.
// dispatchSwitch.cpp #include <chrono> #include <iostream> enum class MessageSeverity{ information, warning, fatal, }; auto start = std::chrono::steady_clock::now(); void writeElapsedTime(){ auto now = std::chrono::steady_clock::now(); std::chrono::duration<double> diff = now - start; std::cerr << diff.count() << " sec. elapsed: "; } void writeInformation(){ std::cerr << "information" << std::endl; } void writeWarning(){ std::cerr << "warning" << std::endl; } void writeUnexpected(){ std::cerr << "unexpected" << std::endl; } void writeMessage(MessageSeverity messSever){ writeElapsedTime(); switch(messSever){ case MessageSeverity::information: writeInformation(); break; case MessageSeverity::warning: writeWarning(); break; default: writeUnexpected(); break; } } int main(){ std::cout << std::endl; writeMessage(MessageSeverity::information); writeMessage(MessageSeverity::warning); writeMessage(MessageSeverity::fatal); std::cout << std::endl; }
I will make it short. Let’s continue with the hash table.
Hashtable
For a more elaborate discussion of the switch statement and the hash table, read my last post: C++ Core Guidelines: To Switch or not to Switch, that is the Question.
// dispatchHashtable.cpp #include <chrono> #include <functional> #include <iostream> #include <unordered_map> enum class MessageSeverity{ information, warning, fatal, }; auto start = std::chrono::steady_clock::now(); void writeElapsedTime(){ auto now = std::chrono::steady_clock::now(); std::chrono::duration<double> diff = now - start; std::cerr << diff.count() << " sec. elapsed: "; } void writeInformation(){ std::cerr << "information" << std::endl; } void writeWarning(){ std::cerr << "warning" << std::endl; } void writeUnexpected(){ std::cerr << "unexpected" << std::endl; } std::unordered_map<MessageSeverity, std::function<void()>> mess2Func{ {MessageSeverity::information, writeInformation}, {MessageSeverity::warning, writeWarning}, {MessageSeverity::fatal, writeUnexpected} }; void writeMessage(MessageSeverity messServer){ writeElapsedTime(); mess2Func[messServer](); } int main(){ std::cout << std::endl; writeMessage(MessageSeverity::information); writeMessage(MessageSeverity::warning); writeMessage(MessageSeverity::fatal); std::cout << std::endl; }
Is this the end? No? In C++, we have dynamic and static polymorphism, as a few of my readers mentioned in their discussion. With the if-else or the switch statement, I used an enumerator to dispatch the correct case. The key of my hash table behaves similarly.
Dynamic or static polymorphism is different. Instead of an enumerator or a key for dispatching the right action, I use objects which decide autonomously at runtime (dynamic polymorphism) or compile-time (static polymorphism) what should be done.
Let’s continue with dynamic polymorphism.
Dynamic polymorphism
Not, the decision logic is encoded in the type hierarchy.
// dispatchDynamicPolymorphism.cpp #include <chrono> #include <iostream> auto start = std::chrono::steady_clock::now(); void writeElapsedTime(){ auto now = std::chrono::steady_clock::now(); std::chrono::duration<double> diff = now - start; std::cerr << diff.count() << " sec. elapsed: "; } struct MessageSeverity{ // (1) virtual void writeMessage() const { std::cerr << "unexpected" << std::endl; } }; struct MessageInformation: MessageSeverity{ // (2) void writeMessage() const override { std::cerr << "information" << std::endl; } }; struct MessageWarning: MessageSeverity{ // (3) void writeMessage() const override { std::cerr << "warning" << std::endl; } }; struct MessageFatal: MessageSeverity{}; void writeMessageReference(const MessageSeverity& messServer){ writeElapsedTime(); messServer.writeMessage(); } void writeMessagePointer(const MessageSeverity* messServer){ writeElapsedTime(); messServer->writeMessage(); } int main(){ std::cout << std::endl; MessageInformation messInfo; MessageWarning messWarn; MessageFatal messFatal; MessageSeverity& messRef1 = messInfo; MessageSeverity& messRef2 = messWarn; MessageSeverity& messRef3 = messFatal; writeMessageReference(messRef1); // (4) writeMessageReference(messRef2); writeMessageReference(messRef3); std::cerr << std::endl; MessageSeverity* messPoin1 = new MessageInformation; MessageSeverity* messPoin2 = new MessageWarning; MessageSeverity* messPoin3 = new MessageFatal; writeMessagePointer(messPoin1); // (5) writeMessagePointer(messPoin2); writeMessagePointer(messPoin3); std::cout << std::endl; }
The classes (1), (2), and (3) know what they have to display if used. The key idea is that the static type MessageSeverity differs from the dynamic type such as MessageInformation(4); therefore, the late binding will kick in, and the writeMessage methods (5), (6), and (7) of the dynamic types are used. Dynamic polymorphism requires a kind of indirection. You can use references (8) or pointers (9).
From a performance perspective, we can do better and make the dispatch at compile time.
Static polymorphism
Static polymorphism is often called CRTP. CRTP stands for the C++ idiom Curiously Recurring Template Pattern. Curiously because a class derives this technique from a class template instantiation using itself as a template argument.
// dispatchStaticPolymorphism.cpp #include <chrono> #include <iostream> auto start = std::chrono::steady_clock::now(); void writeElapsedTime(){ auto now = std::chrono::steady_clock::now(); std::chrono::duration<double> diff = now - start; std::cerr << diff.count() << " sec. elapsed: "; } template <typename ConcreteMessage> // (1) struct MessageSeverity{ void writeMessage(){ // (2) static_cast<ConcreteMessage*>(this)->writeMessageImplementation(); } void writeMessageImplementation() const { std::cerr << "unexpected" << std::endl; } }; struct MessageInformation: MessageSeverity<MessageInformation>{ void writeMessageImplementation() const { // (3) std::cerr << "information" << std::endl; } }; struct MessageWarning: MessageSeverity<MessageWarning>{ void writeMessageImplementation() const { // (4) std::cerr << "warning" << std::endl; } }; struct MessageFatal: MessageSeverity<MessageFatal>{}; // (5) template <typename T> void writeMessage(T& messServer){ writeElapsedTime(); messServer.writeMessage(); // (6) } int main(){ std::cout << std::endl; MessageInformation messInfo; writeMessage(messInfo); MessageWarning messWarn; writeMessage(messWarn); MessageFatal messFatal; writeMessage(messFatal); std::cout << std::endl; }
In this case, all concrete classes (3), (4), and (5) derive from the base class MessageSeverity. The method writeMessage is a kind of interface that dispatches to the concrete implementations writeMessageImplementation. To make that happen, the object will be upcasted to the ConcreteMessage: static_cast<ConcreteMessage*>(this)->writeMessageImplementation();. This is the static dispatch at compile time; therefore, this technique is called static polymorphism.
It took me time to get used to it, but applying the static polymorphism in line (6) is quite easy. If the curiously recurring template pattern is still curious to you, I wrote an article about it: C++ is Lazy: CRTP
To end my comparison, let me compare these various techniques.
My simple comparison
Let’s first look at your preferred way to implement and maintain a control structure. Depending on your experience as a C programmer, the if or switch statements seem pretty natural to you. If you have an interpreter background, you may prefer the hash table. With an object orientation background, dynamic polymorphism is your preferred way to implement the control structure. Static polymorphism, also called CRTP, is quite unique; therefore, it will take some time to get comfortable with it. Afterward, it is quite a pattern you have to use.
I must mention the new context-sensitive identifiers override from the security perspective. It helps to express your intent to override a virtual method in your type hierarchy. If you make it wrong, the compiler will complain.
Now to the more interesting question. What are the performance differences? I will only provide a rough idea without numbers. If you have a long series of if statements, this will become quite expensive because many comparisons are involved. The dynamic polymorphism and the hash table will be faster and in the same ballpark because, in both cases, a pointer indirection is involved. The switch statement and the static polymorphism make their decision at compile time; therefore, they are the two fastest control structures.
What’s next?
I hope I’m done with the discussion of the different control structures; therefore, I will in my next post the last rules to statements and start with the rules for arithmetic expressions.
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 |
Modernes C++ GmbH
Modernes C++ Mentoring (English)
Rainer Grimm
Yalovastraße 20
72108 Rottenburg
Mail: schulung@ModernesCpp.de
Mentoring: www.ModernesCpp.org
Modernes C++ Mentoring,
Leave a Reply
Want to join the discussion?Feel free to contribute!