{"id":6306,"date":"2022-02-18T12:27:07","date_gmt":"2022-02-18T12:27:07","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/dynamic-and-static-polymorphism\/"},"modified":"2023-08-12T16:19:45","modified_gmt":"2023-08-12T16:19:45","slug":"dynamic-and-static-polymorphism","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/dynamic-and-static-polymorphism\/","title":{"rendered":"Dynamic and Static Polymorphism"},"content":{"rendered":"

Polymorphism is the property that different types support the same interface. In C++, we distinguish between dynamic polymorphism and static polymorphism.<\/p>\n

<\/p>\n

\"StaticDynamic\"<\/p>\n

Now we are done with the basics, details, and techniques around templates, let me write about the design with templates. There are many types of polymorphism<\/a>, but I want to concentrate on one aspect. Does the polymorphism dispatch happen at run time or at compile time? Run-time polymorphism is based on object orientation and virtual functions in C++, and compile-time polymorphism is based on templates.<\/p>\n

Both polymorphisms have pros and cons that I discuss in the following post.<\/p>\n

Dynamic Polymorphism<\/h2>\n

Here are the key facts. Dynamic Polymorphism takes place at run time, is based on object orientation, and enables us to separate between the interface and the implementation of a class hierarchy. To get late binding, dynamic dispatch, or dispatch at run time, you need virtuality and an indirection such as a pointer or a reference.<\/p>\n

<\/p>\n

\n
\/\/ dispatchDynamicPolymorphism.cpp<\/span>\n\n#include <chrono><\/span>\n#include <iostream><\/span>\n\nauto<\/span> start =<\/span> std::<\/span>chrono::<\/span>steady_clock::<\/span>now();\n\nvoid<\/span> writeElapsedTime<\/span>(){\n    auto<\/span> now =<\/span> std::<\/span>chrono::<\/span>steady_clock::<\/span>now();\n    std::<\/span>chrono::<\/span>duration<<\/span>double<\/span>><\/span> diff =<\/span> now -<\/span> start;\n  \n    std::<\/span>cerr <<<\/span> diff.count() <<<\/span> \" sec. elapsed: \"<\/span>;\n}\n\nstruct<\/span> MessageSeverity{                         \n\tvirtual<\/span> void<\/span> writeMessage() const<\/span> {         \n\t\tstd::<\/span>cerr <<<\/span> \"unexpected\"<\/span> <<<\/span> '\\n'<\/span>;\n\t}\n};\n\nstruct<\/span> MessageInformation:<\/span> MessageSeverity{     \n\tvoid<\/span> writeMessage() const<\/span> override {        \n\t\tstd::<\/span>cerr <<<\/span> \"information\"<\/span> <<<\/span> '\\n'<\/span>;\n\t}\n};\n\nstruct<\/span> MessageWarning:<\/span> MessageSeverity{         \n\tvoid<\/span> writeMessage() const<\/span> override {        \n\t\tstd::<\/span>cerr <<<\/span> \"warning\"<\/span> <<<\/span> '\\n'<\/span>;\n\t}\n};\n\nstruct<\/span> MessageFatal:<\/span> MessageSeverity{};\n\nvoid<\/span> writeMessageReference<\/span>(const<\/span> MessageSeverity&<\/span> messServer){   \/\/ (1)<\/em><\/span>\n\t\n\twriteElapsedTime();\n\tmessServer.writeMessage();\n\t\n}\n\nvoid<\/span> writeMessagePointer<\/span>(const<\/span> MessageSeverity*<\/span> messServer){    \/\/ (2)<\/span>\n\t\n\twriteElapsedTime();\n\tmessServer-><\/span>writeMessage();\n\t\n}\n\nint<\/span> main<\/span>(){\n\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n  \n    MessageInformation messInfo;\n    MessageWarning messWarn;\n    MessageFatal messFatal;\n  \n    MessageSeverity&<\/span> messRef1 =<\/span> messInfo;        \/\/ (3)<\/span> <\/em>     \n    MessageSeverity&<\/span> messRef2 =<\/span> messWarn;        \/\/ (4)<\/span><\/em>\n    MessageSeverity&<\/span> messRef3 =<\/span> messFatal;       \/\/ (5)<\/span><\/em>\n  \n    writeMessageReference(messRef1);              \n    writeMessageReference(messRef2);\n    writeMessageReference(messRef3);\n  \n    std::<\/span>cerr <<<\/span> '\\n'<\/span>;\n  \n    MessageSeverity*<\/span> messPoin1 =<\/span> new<\/span> MessageInformation;   \/\/ (6)<\/span><\/em>\n    MessageSeverity*<\/span> messPoin2 =<\/span> new<\/span> MessageWarning;       \/\/ (7)<\/span><\/em>\n    MessageSeverity*<\/span> messPoin3 =<\/span> new<\/span> MessageFatal;         \/\/ (8)<\/span><\/em>\n  \n    writeMessagePointer(messPoin1);               \n    writeMessagePointer(messPoin2);\n    writeMessagePointer(messPoin3);\n  \n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n\n}\n<\/pre>\n<\/div>\n
Here is the output of the program.<\/p>\n
\"dispatchDyamicPolymorphis\"<\/p>\n
You may ask yourself why the member function writeMessage<\/code> of the derived class and not the base class is called. Here, late binding kicks in. The following explanation applies to lines (3) to (8). For simplicity, I only write about the line (6): MessageSeverity* messPoin1 = new MessageInformation<\/code>. messPoint1 has essentially two types. A static type MessageSeverity<\/code> and a dynamic type MessageInformation<\/code>. The static type MessageSeverity<\/code> stands for its interface, and the dynamic type MessageInformation<\/code> for its implementation. The static type is used at compile time, and the dynamic type at run time. At run time, messPoint1 is of type MessageInformation<\/code>; therefore, the virtual function writeMessage<\/code> of MessageInformation<\/code> is called. Once more, dynamic dispatch requires an indirection such as a pointer or reference and virtuality.<\/p>\n
I regard this kind of polymorphism as a contract-driven design.<\/strong> A function such as writeMessagePointer<\/code> requires that each object has to support that it is publicly derived from MessageSeverity<\/code>. If this contract is not fulfilled, the compiler complains.<\/p>\n
In contrast to contract-driven design, we also have a behavioral-driven design<\/strong> with static polymorphism.<\/p>\n
Static Polymorphism<\/h2>\n
Let me start with a short detour.<\/p>\n
\"snake<\/p>\n
In Python, you care about behavior and not about formal interfaces. This idea is well-known as duck typing. <\/a>To make it short, the expression goes back to the poem from James <\/a>Whitcomb<\/a> Rileys:<\/a> Here it is:<\/p>\n
\u201cWhen I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.\u201d<\/p>\n
What does that mean? Imagine a function acceptOnlyDucks<\/code>\u00a0that only accepts ducks as an argument. In statically typed languages such as C++, all types which are derived from\u00a0 Duck<\/code> can be used to invoke the function. In Python, all types, which behave like Duck<\/code>‘s, can be used to invoke the function. To make it more concrete. If a bird behaves like a Duck,<\/code> it is a Duck<\/code>. Python often uses a proverb to describe this behavior quite well.<\/p>\n
Don’t ask for permission; ask for forgiveness.<\/p>\n
In our Duck’s case, you invoke the function acceptsOnlyDucks<\/code> with a bird and hope for the best. If something terrible happens, you catch the exception with an except clause. Typically, this strategy works very well and very fast in Python.<\/p>\n
Okay, this is the end of my detour. Maybe you wonder why I wrote about duck typing in this C++ post. The reason is relatively straightforward. Thanks to templates, we have duck typing in C++.<\/p>\n
This means that you can refactor the previous program dispatchStaticPolymorphism.cpp<\/code> using duck typing.<\/p>\n
<\/p>\n
\n
\/\/ duckTyping.cpp<\/span>\n\n#include <chrono><\/span>\n#include <iostream><\/span>\n\nauto<\/span> start =<\/span> std::<\/span>chrono::<\/span>steady_clock::<\/span>now();\n\nvoid<\/span> writeElapsedTime<\/span>(){\n    auto<\/span> now =<\/span> std::<\/span>chrono::<\/span>steady_clock::<\/span>now();\n    std::<\/span>chrono::<\/span>duration<<\/span>double<\/span>><\/span> diff =<\/span> now -<\/span> start;\n  \n    std::<\/span>cerr <<<\/span> diff.count() <<<\/span> \" sec. elapsed: \"<\/span>;\n}\n\nstruct<\/span> MessageSeverity{\n  void<\/span> writeMessage() const<\/span> {\n      std::<\/span>cerr <<<\/span> \"unexpected\"<\/span> <<<\/span> '\\n'<\/span>;\n  }\n};\n\nstruct<\/span> MessageInformation {\n  void<\/span> writeMessage() const<\/span> {              \n    std::<\/span>cerr <<<\/span> \"information\"<\/span> <<<\/span> '\\n'<\/span>;\n  }\n};\n\nstruct<\/span> MessageWarning {\n  void<\/span> writeMessage() const<\/span> {               \n    std::<\/span>cerr <<<\/span> \"warning\"<\/span> <<<\/span> '\\n'<\/span>;\n  }\n};\n\nstruct<\/span> MessageFatal:<\/span> MessageSeverity{};     \n\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\nvoid<\/span> writeMessage(T&<\/span> messServer){    \/\/ (1)                   <\/span>\n\t\n\twriteElapsedTime();                                   \n\tmessServer.writeMessage();                            \n\t\n}\n\nint<\/span> main(){\n\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n  \n    MessageInformation messInfo;\n    writeMessage(messInfo);\n    \n    MessageWarning messWarn;\n    writeMessage(messWarn);\n\n    MessageFatal messFatal;\n    writeMessage(messFatal);\n  \n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n\n}\n<\/pre>\n<\/div>\n
The function template writeMessage<\/code> (line 1) applies duck typing. writeMessage<\/code> assumes that all objects messServer support the member function writeMessage<\/code>. If not, the compilation would fail. The main difference to Python is that the error happens in C++ at compile time, but in Python at run time. Finally, here is the output of the program.<\/p>\n
\"duckTyping\"<\/p>\n
The function writeMessage<\/code> behaves polymorphic but is neither type-safe nor writes a readable error message in case of an error. At least I can quickly fix the last issue with concepts in C++20. You can read more about concepts in my previous posts about concepts<\/a>. In the following example, I define and use the concept MessageServer<\/code> (line 1).<\/p>\n
<\/p>\n
\n
\/\/ duckTypingWithConcept.cpp<\/span>\n\n#include <chrono><\/span>\n#include <iostream><\/span>\n\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>   \/\/ (1)<\/span>\nconcept MessageServer =<\/span> requires(T t) {\n    t.writeMessage();\n};\n\nauto<\/span> start =<\/span> std::<\/span>chrono::<\/span>steady_clock::<\/span>now();\n\nvoid<\/span> writeElapsedTime<\/span>(){\n    auto<\/span> now =<\/span> std::<\/span>chrono::<\/span>steady_clock::<\/span>now();\n    std::<\/span>chrono::<\/span>duration<<\/span>double<\/span>><\/span> diff =<\/span> now -<\/span> start;\n  \n    std::<\/span>cerr <<<\/span> diff.count() <<<\/span> \" sec. elapsed: \"<\/span>;\n}\n\nstruct<\/span> MessageSeverity{\n  void<\/span> writeMessage() const<\/span> {\n      std::<\/span>cerr <<<\/span> \"unexpected\"<\/span> <<<\/span> '\\n'<\/span>;\n  }\n};\n\nstruct<\/span> MessageInformation {\n  void<\/span> writeMessage() const<\/span> {              \n    std::<\/span>cerr <<<\/span> \"information\"<\/span> <<<\/span> '\\n'<\/span>;\n  }\n};\n\nstruct<\/span> MessageWarning {\n  void<\/span> writeMessage() const<\/span> {               \n    std::<\/span>cerr <<<\/span> \"warning\"<\/span> <<<\/span> '\\n'<\/span>;\n  }\n};\n\nstruct<\/span> MessageFatal:<\/span> MessageSeverity{};     \n\ntemplate<\/span> <<\/span>MessageServer T><\/span>   \/\/ (2)<\/span>\nvoid<\/span> writeMessage(T&<\/span> messServer){                       \n\t\n\twriteElapsedTime();                                   \n\tmessServer.writeMessage();                            \n\t\n}\n\nint<\/span> main(){\n\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n  \n    MessageInformation messInfo;\n    writeMessage(messInfo);\n    \n    MessageWarning messWarn;\n    writeMessage(messWarn);\n\n    MessageFatal messFatal;\n    writeMessage(messFatal);\n  \n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n\n}\n<\/pre>\n<\/div>\n
The concept MessageServer (line 1) requires that an object t<\/code> of type T<\/code> has to support the call t.writeMessage. <\/code>Line (2) applies the concept in the function template writeMessage<\/code>.<\/p>\n
What’s next?<\/h2>\n
So far, I have only written about the polymorphic behavior of templates but not static polymorphism. This changes in my next post. I present the so-called CRTP idiom. CRTP stands for the C<\/strong>uriously R<\/strong>ecurring T<\/strong>emplate P<\/strong>attern and means a technique in C++ in which you inherit a class Derived<\/code> from a template class Base<\/code> and Base<\/code> has Derived<\/code> as a template parameter:<\/p>\n
<\/p>\n
\n
template<\/span> <<\/span>typename<\/span> T><\/span>\nclass<\/span> Base<\/span>\n{\n    ...\n};\n\nclass<\/span> Derived<\/span> :<\/span> public<\/span> Base<<\/span>Derived><\/span>\n{\n    ...\n};\n<\/pre>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Polymorphism is the property that different types support the same interface. In C++, we distinguish between dynamic polymorphism and static polymorphism.<\/p>\n","protected":false},"author":21,"featured_media":6303,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[376],"tags":[427],"class_list":["post-6306","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-templates","tag-polymorphism"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/6306","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=6306"}],"version-history":[{"count":2,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/6306\/revisions"}],"predecessor-version":[{"id":8055,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/6306\/revisions\/8055"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/6303"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=6306"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=6306"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=6306"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
The function writeMessageReference<\/code> (line 1) or writeMessagePointer<\/code> (line 2) require a reference or a pointer to an object of type MessageSeverity<\/code>. Classes publicly derived from MessageSeverity<\/code> such as MessageInformation<\/code>, MessageWarning<\/code>, or MessageFatal<\/code> support the so-called\u00a0Liskov substitution principle<\/a>. This means that a MessageInformation<\/code>, MessageWarning<\/code>, or a MessageFatal<\/code> is a MessageSeverity<\/code>.<\/p>\n