Search code examples
c++design-patternslanguage-agnosticstatic-polymorphism

Static polymorphism definition and implementation


I have some questions about the concept of static polymporhism I somethimes hear about; you may interpret them primarily in the context of C++, but I'd appreciate language-agnostic answers where applicable (hence tagging both C++ and language-agnostic).

  1. How do we define static polymorphism in general? As an example, I believe that the std::sort function from C++ shall be considered statically polymorphic as it depends on some interface provided by some objects which behave like iterators, and the exact behaviour under the interface of provided iterators can be determined in the compile-time. Is this explanation how we define static polymorphism, or is it just a description of a specific case and there's more to it?

  2. What are the common code patterns of using static polymorphism in C++? Also: Is SP only achieved via templates in C++?

  3. Is it true that a given UML class diagram doesn't directly describe how polymorphism is handled and, thus, it can be at least partially implemented either statically or dynamically? In other words: Is the choice of static vs dynamic polymorphism independent of the OOP model, and thus up to the implementor to decide?

  4. Is static polymorphism only C++-specific and related to how templates work? If not, is it present in any other mainstream languages besides C++? Can we have an equivalent of static polymorphism in Java, C#.. anything, and will it bring any benefits?

  5. The most important... What are the actual benefits of using static polymorphism? I think we can agree that it reduces code flexibility; what are the advantages, besides - in the case of C++ - saving one pointer dereference (virtual function / pointer-to-function / delegate cost)? What is the class of problems where static polymorphism is especially useful, the right choice for implementation?


Solution

    1. Static polymorphic behavior is type polymorphism that occurs at compile time rather than run time.
    2. Yes.
    3. UML is about how classes interact at runtime -- I don't believe there's a UML format for describing templates, but I could be wrong.
    4. As far as I am aware it is C++ specific, but I'm not positive given that I've not used every language ever invented. :) That said, JIT'd languages like C# and Java often are very good at removing the performance impact of indirect calls in some cases using information gleaned at runtime rather than at compile time. Whether this is at compile time or not is kind of up on the air though... after all, it is called a Just-In-Time Compiler.
    5. The main benefit is simply performance. Runtime polymorphism can do everything static polymorphism can do (in fact it can do more), but it carries the cost of indirect calls (which can be expensive if there are enough of 'em)

    Now, templates themselves have many uses beyond achieving compile time polymorphism -- for example the SFINAE magic that makes boost::bind work is certainly not polymorphic -- it's merely there in order to smooth over inconsistencies in the language itself.