DEV Community: Félix-Olivier Dumas

Static Interface Projection Pattern (SIPP): Static Control of Method Exposure in C++

Félix-Olivier Dumas — Sun, 14 Jun 2026 16:37:06 +0000

Introduction and context

Nowadays, C++ is one of the most influential programming languages in the world. Over the past 40 years, it has proven itself in fields ranging from aerospace engineering to your basement at 2 a.m.

What is most striking is that we often forget the origin of this pillar of modern programming. Stroustrup originally named his project “C with Classes,” since it added object-oriented features to C without modifying the underlying language itself. It is therefore obvious that polymorphism plays a central role in the philosophy of this language.

To this day, there are two major categories when it comes to polymorphism in C++: static polymorphism and dynamic polymorphism. Although they share the same underlying philosophy, the reality is that they are extremely different from one another, both in implementation and in usage.

In today’s article, we will mainly focus on static polymorphism. Not because virtual polymorphism is uninteresting, but because the two differ so much that they would each require a full article of their own. So feel free to settle in and enjoy what follows!

Understanding polymorphism

First of all, it is important to explain what polymorphism is in C++. If you are reading this article, I assume you already understand the general concept of polymorphism, but I will still take a moment to briefly explain it.

In programming language theory and type theory, polymorphism allows a value or variable to have more than one type and allows a given operation to be performed on values of more than one type.

In object-oriented programming, polymorphism is the provision of one interface to entities of different data types. The concept is borrowed from a principle in biology in which an organism or species can have many different forms or stages.

— Source: Wikipedia, Polymorphism (programming language theory)

The explanation from the citation above is particularly effective, as it touches on one of the core ideas of the concept: interfaces. An interface can be seen as a contract, an obligation, or a structural constraint. For example, if a cat claims to be a feline, it is bound by the contract of exhibiting feline behavior in some form or another. Thus, when we see a cat, we can assume it can hunt, since felines hunt.

Let’s put felines aside and move on to a more concrete, code-oriented approach. From this point on, I will present examples in C++. “Talk is cheap, show me the code.”:

#include <iostream>

struct Felin {
    virtual ~Felin() = default;
    virtual void hunt() = 0;
};

struct Cat : Felin {
    void hunt() override {
        // hunts a mouse, an insect, etc.
        std::cout << "Cat hunts\n";
    }
};

Here, you can see that the Felin struct defines the contract via the hunt method. Then you can notice that the Cat struct inherits from Felin, which automatically forces it to respect the contract and therefore provide its own implementation of the required method.

Finally, for the more observant among you, you may have noticed the slightly unusual syntax with the keywords virtual and override. This is not surprising, since it represents a form of virtual polymorphism. As mentioned earlier, we will not really cover this category. There are many resources available, and I encourage you to explore them if you are curious about how it works.

Static Polymorphism in C++

Static polymorphism is a programming mechanism in which the correct implementation is selected at compile time, based on the types known at that moment. In other words, a single interface can be used with different types, but the choice of which version is executed is resolved before the program runs, by the compiler.

It is important to understand that static polymorphism is not a single technique, but rather a set of techniques sharing the same fundamental constraints. To illustrate this concretely, let’s examine one of the most common uses of CRTP:

#include <iostream>
#include <utility>

struct Base {
    template <typename Self>
    void interface(this Self&& self) {
        std::forward<Self>(self).implementation();
    }
};

struct Derived : Base {
    void implementation() {
        std::cout << "Implementation from Derived\n";
    }
};

Analysis of the CRTP Example

As you can see, the example above is significantly more complex than the one we discussed earlier. This is not accidental, since it requires replicating, entirely at compile time, the behavior that the compiler would normally handle with virtual polymorphism.

Here, we are also using the latest C++23 standard features to greatly simplify the pattern’s implementation. The use of the explicit this parameter allows us to retrieve the object from which the function is called. In this example, the interface method will always be invoked on the derived object Derived, which allows it to directly call the implementation method on that object.

template <typename Self>
void interface(this Self&& self) { // self = derived type
    std::forward<Self>(self).implementation(); // call implementation method
}

Advantages of Static Polymorphism

Why use static polymorphism? For the simple reason that it provides significant performance gains compared to virtual polymorphism. In addition, it offers a great deal of flexibility in design, since it allows you to modify the behavior of polymorphic delegation, something that is not normally possible with the virtual approach.

#include <utility>

struct Base {
    template <typename Self>
    void interface(this Self&& self) {
        std::forward<Self>(self).implementationA();
        std::forward<Self>(self).implementationB();
    }
};

Here, we call two methods sequentially from the base interface method, which is normally impossible with virtual polymorphism. As another example, it would even be possible to measure the execution time of the derived method by starting a timer before the call and stopping it afterward.

Limitations and Drawbacks

Although it may seem perfect at first glance, static polymorphism has many obvious issues that prevent it from fully replacing its virtual counterpart. I have therefore selected the main drawbacks associated with its use.

Code Complexity and Readability

First of all, there is obviously the added complexity and reduced readability of its implementation. It is well known that nothing is free, and you inevitably pay for these performance gains with increased complexity. This is also why this approach is generally used in environments where performance is critical and readability is almost secondary.

Slicing and Storage Issues

And that’s not all, because objects using this approach cannot be stored in the same way as those using virtual polymorphism. For example, you cannot store Cat objects inside a std::vector<Felin> by value, because this leads to slicing: only the part corresponding to the base class is preserved during copying, while the derived part is lost. This is what is known as “slicing”, although I will avoid going into further detail for the sake of the target audience. However, there is a solution, but it introduces a significant increase in complexity and reduced readability—you can judge for yourself:

#include <iostream>
#include <variant>
#include <vector>

struct Shape {
    template <typename Self>
    void draw(this Self&& self) {
        self.draw_impl();
    }
};

struct Circle {
    void draw_impl() {
        std::cout << "Circle\n";
    }
};

struct Square {
    void draw_impl() {
        std::cout << "Square\n";
    }
};

using AnyShape = std::variant<Circle, Square>;

int main() {
    std::vector<AnyShape> shapes = { Circle{}, Square{}, Circle{} };

    for (auto& s : shapes) {
        std::visit([](auto& shape) {
            shape.draw();
        }, s);
    }
}

Exposure of Implementation Methods

Finally, one of the issues that bothers me the most is that implementation methods are always visible and accessible from the derived object. This exposes methods unnecessarily, bloats the public API of the object, and is generally “messy”. Here is a small example so you can see what I mean:

#include <iostream>

struct Circle {
    void draw_impl() {
        std::cout << "Circle\n";
    }
};

int main() {
    Circle c{};
    c.draw_impl(); // visible and accessible
}

Interim Conclusion

To conclude this section, you may have noticed that I avoid going too deep into the technical details of how all these concepts work. This is mainly because that is not the focus of this article. This section is meant more as context than as a technical deep dive. That said, I have already written a large and highly technical article on static polymorphism and CRTP. In it, I also present an experimental approach called “exotic CRTP”, which may interest the more curious readers among you.

SIPP: an Experimental Approach to Static Polymorphism

Pattern Overview

Now that you understand some of the main drawbacks of static polymorphism, I can share what I have been experimenting with over the past few days. Here is the result of my experiments on the matter.

#include <iostream>

struct Implementation {
    void foo() {
        std::cout << "foo\n";
    }

    void bar() {
        std::cout << "bar\n";
    }
};

template<typename Impl>
struct Interface : private Impl {
    using Impl::foo;
    using Impl::bar;
};

First of all, I must say that I spent a long time searching online for similar implementations to what I have been experimenting with, but unfortunately, I found nothing concrete. However, I am certain I am not the first to discover this, because it feels far too obvious.

For all these reasons, I decided to name it: Static Interface Projection Pattern, or SIPP.

Understanding How SIPP Works

At first, it may seem a bit unclear, but we will gradually go through each part of this code to better understand it.

Let’s start by looking at the code. You may notice that the typical “Derived inherits Base” model appears inverted here. In fact, the interface acts as a view over an implementation. More precisely, it filters which methods are exposed externally. So if we look at the example above, the only methods callable from an Interface<Implementation> object are foo and bar:

#include <iostream>

struct Implementation {
    void foo() {}
    void bar() {}
};

template<typename Impl>
struct InterfaceA : private Impl {
    using Impl::foo;
};

template<typename Impl>
struct InterfaceB : private Impl {
    using Impl::bar;
};

int main() {
    InterfaceA<Implementation> objA;
    InterfaceB<Implementation> objB;

    objA.foo();
    objB.bar();
}

Inversion of the Contract Model

As you can understand, the Implementation (Derived) no longer inherits a contract: the contract itself is what gets applied to it. In this way, the Implementation class becomes completely independent and decoupled from any contractual structure. This results in a kind of inversion, where both the polymorphic contract and the implementation must now accommodate each other for the contract to work. It is somewhat like moving from a relationship where only one person makes the decisions to a relationship where both parties have a say.

A Symmetrical Contractual Relationship

In this way, we create a symmetrical contractual polymorphic relationship. For example, if an Interface class exposes the method foo, the implementation class must necessarily provide that method in an accessible way; otherwise, the contract cannot be validated (the compiler will simply fail because the method foo does not exist in Impl). On the other hand, the implementation class itself can expose additional methods outside the contract, but only the methods defined by the contract will be accessible from the outside.

Extension to Multiple Inheritance and Contract Composition

Now, there is the topic of multiple inheritance, which becomes somewhat ambiguous. This model is primarily designed for a 1:1 relationship between interface and implementation, but it could also be extended to multiple inheritance with some caution. I have therefore prepared an example of what this could look like:

#include <iostream>

template<typename... Interfaces>
struct MultiInterface : public Interfaces... {};

struct Implementation {
    void foo() { std::cout << "foo\n"; }
    void bar() { std::cout << "bar\n"; }
};

template<typename Impl>
struct InterfaceA : private Impl {
    using Impl::foo;
};

template<typename Impl>
struct InterfaceB : private Impl {
    using Impl::bar;
};

int main() {
    MultiInterface<
        InterfaceA<Implementation>,
        InterfaceB<Implementation>
    > obj;

    obj.foo();
    obj.bar();
}

As you can see, this quickly becomes very heavy in terms of readability. It would be better to use aliases to reduce the burden of these rather “demonic” type signatures. As for the implementation itself, it is not actually that complicated: we use a wrapper that inherits and publicly exposes all methods from the contracts that compose it. It is simple and effective, but it is not entirely 100% safe, because there is always a risk that two contracts expose the same method, which would result in an ambiguous call.

However, and I must emphasize this, this pattern is not really intended for use cases where multiple inheritance is a primary requirement.

Practical Applications of SIPP

This unusual relationship leads us to understand that this form of static polymorphism opens many doors in the design of ultra-high-performance object-oriented architectures. To illustrate this properly, here are two very interesting examples that use this pattern.

First Example: Logging System

Here is the first example: a simple implementation of a logging system where the logger can be viewed in two different states depending on the chosen contract:

#include <iostream>

struct ConsoleLogger {
    void write() {
        std::cout << "write to console\n";
    }

    void flush() {
        std::cout << "flush console\n";
    }

    void debug() {
        std::cout << "debug: console\n";
    }
};

template<typename Impl>
struct LoggingInterface : private Impl {
    using Impl::write;
    using Impl::flush;
};

template<typename Impl>
struct DebugLoggingInterface : private Impl {
    using Impl::write;
    using Impl::flush;
    using Impl::debug;
};

int main() {
    LoggingContract<ConsoleLogger> console_logger;

    console_logger.write();
    console_logger.flush();

    DebugLoggingContract<ConsoleLogger> debug_console_logger;

    debug_console_logger.debug(); // newly exposed method
    debug_console_logger.write();
    debug_console_logger.flush();
}

In this example, you can see that the first view, LoggingContract, exposes only the write and flush methods. Similarly, the second view, DebugLoggingContract, exposes the same methods as the first one, but additionally exposes the debug method.

In this way, it is possible to represent a single object in two completely different ways without modifying its implementation. The ConsoleLogger class only needs to implement whatever methods it wants, and it is the views/contracts that handle the exposure. Finally, this helps keep a clean and highly extensible API, thanks to the simplicity of the contracts: you only need to add a using Impl::my_method; for it to become exposed.

Second Example: Contract Reinterpretation and Cast

This second example is a bit more technical and may be somewhat more controversial than the previous one. It is not necessarily the most important part, but it involves some slightly “hacky” manipulations that are not intended for everyone. Without further delay, here it is:

#include <iostream>
#include <type_traits>

struct ConsoleLogger {
    void write() {
        std::cout << "write\n";
    }

    void flush() {
        std::cout << "flush\n";
    }

    void debug() {
        std::cout << "debug\n";
    }
};

template<typename Impl>
struct LoggingContract : private Impl {
    using Impl::write;
    using Impl::flush;
};

template<typename Impl>
struct DebugLoggingContract : private Impl {
    using Impl::write;
    using Impl::flush;
    using Impl::debug;
};

int main() {
    LoggingContract<ConsoleLogger> console_logger;

    console_logger.write();
    console_logger.flush();

    auto& debug_console_logger =
        reinterpret_cast<DebugLoggingContract<ConsoleLogger>&>(console_logger);

    debug_console_logger.debug();

    static_assert(std::is_layout_compatible_v<
        LoggingContract<ConsoleLogger>,
        DebugLoggingContract<ConsoleLogger>
    >);
}

As you can see, I use a reinterpret_cast to transform my initial view using LoggingContract into another view, DebugLoggingContract. At first glance, this may seem somewhat esoteric, and it is—but there is still a certain logic behind this manipulation.

The first question to ask is probably: why does this even compile in the first place? The answer is simpler than you might think. In reality, LoggingContract<ConsoleLogger> and DebugLoggingContract<ConsoleLogger> are exactly the same in memory. In fact, I verified this using the standard library utility std::is_layout_compatible_v<T, V>, and the result was true.

However, functional does not automatically mean safe. I will avoid going too deep into how ABI and class memory layout work on most compilers, but the key takeaway is that, in memory, these empty view types that inherit from the same implementation are effectively identical. This works well in practice, but it is only an ABI convention and not something guaranteed by the standard.

On the other hand, this approach allows transforming the object without performing any runtime operation, making it almost zero-cost. This mainly avoids the need for copying or assignment, which is clearly non-negligible in performance-critical systems. It is a cost to pay, and whether it is acceptable depends on your use case.

Beyond all these caveats, this cast mainly allows us to reinterpret the view of an object without changing its underlying nature. In fact, the debug_console_logger obtained from the reinterpret_cast points to the exact same object as the original LoggingContract view. This means we can reinterpret the polymorphic contract of an object at compile time, which I find extremely interesting.

Third Example: Safe Conversion Between Views

This third and final example is intended to address the safety issues of the previous example. Indeed, I chose not to place this example before the other one, because it deals with slightly different techniques compared to the base pattern. Here it is:

#include <iostream>
#include <type_traits>

struct ConsoleLogger {
    ConsoleLogger() = default;

    ConsoleLogger& operator=(const ConsoleLogger& other) {
        return *this;
    }

    void write() {
        std::cout << "write\n";
    }

    void flush() {
        std::cout << "flush\n";
    }

    void debug() {
        std::cout << "debug\n";
    }
};

template<typename Impl>
struct LoggingContract : private Impl {
    explicit LoggingContract(Impl& m) : Impl(m) {} // to assign the base at creation time

    using Impl::Impl;

    using Impl::write;
    using Impl::flush;
};

template<typename Impl>
struct DebugLoggingContract : private Impl {
    explicit DebugLoggingContract(Impl& m) : Impl(m) {} 

    using Impl::Impl;

    using Impl::write;
    using Impl::flush;
    using Impl::debug;
};

int main() {
    ConsoleLogger console_logger_impl;

    LoggingContract<ConsoleLogger> console_logger{ console_logger_impl }; // supports construction from the implementation type

    console_logger.write();
    console_logger.flush();

    DebugLoggingContract<ConsoleLogger> debug_console_logger;

    debug_console_logger = console_logger_impl; // also supports assignment from the implementation type

    debug_console_logger.debug();
}

As you can see, this version also primarily aims to allow assigning an object to different views. It does so by using a delegating constructor inside the view, which allows it to receive an object of type Impl in order to initialize the base. In addition, it exposes implementation-specific methods using using Impl::Impl, which in our case also enables the assignment operator to be exposed.

It is important to note that the mechanism used here is fully safe and part of the language design. However, although it may seem like a better option than the previous example, it still has a major drawback: performance cost. Indeed, passing parameters through constructors and using the assignment operator introduce additional runtime overhead. This is not catastrophic, but in a system where this pattern is used extensively, it can start to become expensive. Finally, it also introduces some additional complexity and reduces readability, which is not negligible, since the added elements in this version will be present in every view and implementation of the system.

Final Conclusion

To conclude, I would like to say a few words to those who made it all the way through this article. First of all, thank you for reading my work, I am truly grateful.

Next, I want to make it clear that I do not claim to have invented a pattern. I am simply highlighting a very interesting variation of existing ideas. I also had the intention of giving this technique a name, and I am not entirely sure how the C++ community reacts to this kind of thing, but I do it with good intentions.

I see a future in this pattern, and I truly believe there is something much bigger to be explored here. And with that, this concludes my second article ever. It is much less technical than my first one, and that was intentional. Simplifying complex ideas is an art, and it is key to learning.

[Boost]

Félix-Olivier Dumas — Fri, 12 Jun 2026 19:58:46 +0000

Félix-Olivier Dumas

Jun 12

Static Interface Projection Pattern (SIPP) : contrôle statique de l’exposition des méthodes en C++

#showdev #programming #opensource #architecture

13 min read

Static Interface Projection Pattern (SIPP) : contrôle statique de l’exposition des méthodes en C++

Félix-Olivier Dumas — Fri, 12 Jun 2026 19:58:01 +0000

Introduction et contexte

De nos jours, le C++ est l'un des langages les plus influents du monde entier. Depuis les 40 dernières années, celui-ci a su faire ses preuves autant dans l'aérospatiale que dans votre sous-sol à 2 h du matin.

Le plus dingue est que nous avons tous tendance à oublier l'origine de ce pilier de la programmation moderne. En effet, Stroustrup avait initialement baptisé son nouveau projet « C avec des classes », car il ajoutait des fonctionnalités orientées objet au C sans modifier le langage sous-jacent. Il est donc évident que le polymorphisme joue un rôle central dans la philosophie de ce langage.

À ce jour, il existe deux grandes catégories lorsqu'il est question du polymorphisme en C++ : le polymorphisme statique et le polymorphisme dynamique. Bien que ceux-ci présentent une même philosophie commune, la réalité est qu'ils sont extrêmement différents l'un de l'autre, tant dans leur implémentation que dans leur utilisation.

Dans l'article d'aujourd'hui, nous aborderons principalement le polymorphisme statique. Non pas que le polymorphisme virtuel ne soit pas intéressant, mais il faut comprendre qu'ils diffèrent tellement l'un de l'autre qu'ils nécessiteraient, à eux deux, un article complet à part entière. Je vous invite donc à vous installer et à profiter de ce qui suit !

Comprendre le polymorphisme

En premier lieu, il est important d'expliquer ce qu'est le polymorphisme en C++. Si vous êtes ici en train de lire cet article, je me doute bien que vous comprenez déjà ce qu'est le concept plus générique de polymorphisme, mais je vais tout de même prendre un petit moment pour brièvement expliquer ce que c'est.

En informatique et en théorie des types, le polymorphisme [...] est le concept consistant à fournir une interface unique à des entités pouvant avoir différents types. Par exemple, des opérations telles que la multiplication peuvent ainsi être étendues des scalaires aux vecteurs ou aux matrices, l'addition des scalaires aux fonctions ou aux chaînes de caractères, etc.

Selon le langage informatique employé, le polymorphisme peut être réalisé par différents moyens, inhérents au langage ou par emploi de patrons de conception.

— Source : Wikipédia, Polymorphisme (informatique)

L'explication tirée de la citation ci-dessus est particulièrement efficace, car elle aborde l'un des piliers du concept, qui est celui des interfaces. Une interface peut être vue comme un contrat, une obligation ou une contrainte morphologique. Par exemple, si un chat prétend être un félin, il a le contrat de présenter, d'une façon ou d'une autre, les comportements d'un félin. Ainsi, si l'on voit un chat, nous pouvons prétendre qu'il sait chasser, car les félins chassent.

Mettons un peu les félins de côté et passons à une approche plus concrète, centrée sur le code. D'ailleurs, je dois préciser qu'à partir de maintenant jusqu'à la fin de cet article, je présenterai des exemples en C++. Ok, “Talk is cheap, show me the code.” :

#include <iostream>

struct Felin {
    virtual ~Felin() = default;
    virtual void hunt() = 0;
};

struct Chat : Felin {
    void hunt() override {
        // chasse une souris, un insecte, etc.
        std::cout << "Chat chasse\n";
    }
};

Ici, vous pouvez apercevoir que la struct Felin présente le contrat de la méthode « hunt ». Ensuite, vous pouvez remarquer que la struct « Chat » hérite de « Felin », ce qui l'oblige automatiquement à respecter le contrat et à, conséquemment, avoir sa propre implémentation de la méthode contractuelle. Ainsi, comme nous l'avions brièvement abordé précédemment, pour qu'un objet puisse être interprété comme un « Felin », il doit en hériter et en respecter son contrat.

Enfin, pour les plus observateurs d'entre vous, vous aurez probablement remarqué que l'exemple ci-dessus utilise une syntaxe un peu atypique avec les mots-clés « virtual » et « override ». Ce n'est pas particulièrement étonnant, car il présente une structure utilisant le polymorphisme virtuel. Comme je l'ai dit précédemment, nous n'aborderons pas vraiment cette catégorie de polymorphisme. Nombreuses sont les ressources à votre disposition ; je ne peux que vous inviter à vous y rendre afin de mieux comprendre son fonctionnement si vous êtes curieux.

Le polymorphisme statique en C++

Le polymorphisme statique est un mécanisme de programmation dans lequel la sélection de la bonne implémentation est effectuée à la compilation, en fonction des types connus à ce moment-là. Autrement dit, une même interface peut être utilisée avec différents types, mais le choix de la version exécutée est résolu avant l’exécution du programme, par le compilateur.

Il est important de comprendre que le polymorphisme statique n'est pas qu'une seule technique, mais bien plusieurs, arborant les mêmes contraintes fondamentales. Pour illustrer cela concrètement, examinons l’une des utilisations les plus courantes du CRTP :

#include <iostream>
#include <utility>

struct Base {
    template <typename Self>
    void interface(this Self&& self) {
        std::forward<Self>(self).implementation();
    }
};

struct Derived : Base {
    void implementation() {
        std::cout << "Implementation from Derived\n";
    }
};

Analyse de l’exemple CRTP

Comme vous pouvez le voir, l'exemple ci-dessus est drastiquement plus dense en complexité que celui que nous avions précédemment abordé plus haut. Ce n'est pas anodin, car il faut répliquer, entièrement à la compilation, le comportement que le compilateur effectuerait normalement avec le polymorphisme virtuel.

D'ailleurs, ici, l'on utilise les dernières fonctionnalités du standard C++23 afin de considérablement simplifier l'exécution de ce pattern. L'utilisation du paramètre explicite « this » permet de récupérer l'objet depuis lequel la fonction est appelée. Concernant l'exemple, la méthode interface sera normalement toujours appelée depuis l'objet dérivé « Derived », ce qui lui permet d'appeler la méthode implementation directement sur cet objet.

template <typename Self>
void interface(this Self&& self) { // self = dérivé
    std::forward<Self>(self).implementation(); // appel de la méthode implémentation
}

Avantages du polymorphisme statique

Maintenant, pourquoi utiliser le polymorphisme statique ? Pour la simple et bonne raison que celui-ci apporte des gains non négligeables en performance en comparaison avec le polymorphisme virtuel. De plus, celui-ci permet une très grande flexibilité sur le design, car il est possible de modifier le comportement de la délégation polymorphique, ce qui n'est normalement pas possible avec l'approche virtuelle.

#include <utility>

struct Base {
    template <typename Self>
    void interface(this Self&& self) {
        std::forward<Self>(self).implementationA();
        std::forward<Self>(self).implementationB();
    }
};

Ici, nous appelons deux méthodes à la suite depuis la méthode interface de la base, ce qui est normalement impossible avec le polymorphisme virtuel. Pour vous donner d'autres exemples, il serait possible de chronométrer le temps d'exécution de la méthode du dérivé en démarrant un chronomètre avant l'appel de la méthode et en l'arrêtant à la fin.

Limites et désavantages

Bien qu'il semble parfait à première vue, le polymorphisme statique a de nombreux problèmes évidents qui l'empêchent de totalement remplacer son rival virtuel. Ainsi, j'ai sélectionné les principaux problèmes qui accompagnent son utilisation.

Complexité et lisibilité du code

En premier lieu, il y a bien évidemment la charge en complexité et en lisibilité de son implémentation. C'est bien connu, rien n'est gratuit et vous payez décidément ces gains en complexité. D'ailleurs, c'est pour cette raison que cette approche est généralement utilisée dans des environnements où les performances sont critiques et où la lisibilité est presque secondaire.

Problèmes de slicing et de stockage

Oh, et ce n'est pas tout, car les objets l'utilisant ne peuvent pas être stockés comme ceux utilisant le polymorphisme virtuel le sont. Par exemple, vous ne pouvez pas stocker des objets Chat dans un « std::vector » par valeur, car cela entraîne du slicing : seule la partie correspondant à la classe de base est conservée lors de la copie, et la partie dérivée est perdue. C'est d'ailleurs ce qu'on appelle le « slicing », mais je vais éviter d'entrer dans les détails pour des raisons de public cible. Cependant, il existe une solution, mais elle introduit une énorme charge en complexité et en lisibilité, à vous d'en juger :

#include <iostream>
#include <variant>
#include <vector>

struct Shape {
    template <typename Self>
    void draw(this Self&& self) {
        self.draw_impl();
    }
};

struct Circle {
    void draw_impl() {
        std::cout << "Circle\n";
    }
};

struct Square {
    void draw_impl() {
        std::cout << "Square\n";
    }
};

using AnyShape = std::variant<Circle, Square>;

int main() {
    std::vector<AnyShape> shapes = { Circle{}, Square{}, Circle{} };

    for (auto& s : shapes) {
        std::visit([](auto& shape) {
            shape.draw();
        }, s);
    }
}

Exposition des méthodes d’implémentation

Et puis enfin, l'un des problèmes qui me fatigue le plus, c'est que les méthodes d'implémentation sont toujours visibles et accessibles depuis l'objet dérivé. Cela expose les méthodes inutilement, remplit inutilement l’API publique de l’objet et c’est globalement « sale ». En voici un petit exemple afin que vous compreniez :

#include <iostream>

struct Circle {
    void draw_impl() {
        std::cout << "Circle\n";
    }
};

int main() {
    Circle c{};
    c.draw_impl(); // visible et accessible
}

Conclusion intermédiaire

Pour terminer cette partie, vous avez sans doute remarqué que j’évite de trop entrer dans les détails concernant le fonctionnement de tous ces concepts. C’est principalement pour la raison que là n’est pas le sujet de cet article. Cette section sert davantage de contexte que d’analyse technique. En revanche, j’ai déjà écrit un article gigantesque et très technique sur le sujet du polymorphisme statique et du CRTP. J’y présente d’ailleurs une approche un peu expérimentale appelée « exotic CRTP », qui pourrait intéresser les plus curieux parmi vous.

SIPP : une approche expérimentale du polymorphisme statique

Présentation du pattern

Maintenant que vous comprenez certains des principaux désavantages qu’apporte le polymorphisme statique, je peux vous partager ce sur quoi j’ai longuement expérimenté lors des derniers jours. Voici le résultat de mes expérimentations en la matière.

#include <iostream>

struct Implementation {
    void foo() {
        std::cout << "foo\n";
    }

    void bar() {
        std::cout << "bar\n";
    }
};

template<typename Impl>
struct Interface : private Impl {
    using Impl::foo;
    using Impl::bar;
};

Avant tout, je dois dire que j'ai longuement recherché sur internet afin de trouver des implémentations similaires à ce que j'ai expérimenté, mais malheureusement, je n'ai rien trouvé de concret. Par contre, je suis certain de ne pas être le premier à découvrir cela, car ça semble beaucoup trop évident.

C’est pour toutes ces raisons que j’ai décidé de l’appeler : Static Interface Projection Pattern, ou SIPP.

Comprendre le fonctionnement du SIPP

Dans un premier temps, ça peut sembler un peu incompréhensible, mais nous allons tranquillement aborder chaque aspect de ce code afin de mieux l’appréhender.

Commençons par observer le code. Vous pouvez remarquer que le modèle typique de « Derived » qui hérite de « Base » semble inversé. En effet, l’interface fait ici office de vue sur une implémentation. Pour être plus précis, elle filtre les méthodes qui seront accessibles depuis l’extérieur. Donc si l’on regarde l’exemple ci-dessus, les seules méthodes appelables depuis l’objet « Interface » sont « foo » et « bar » :

#include <iostream>

struct Implementation {
    void foo() {}
    void bar() {}
};

template<typename Impl>
struct InterfaceA : private Impl {
    using Impl::foo;
};

template<typename Impl>
struct InterfaceB : private Impl {
    using Impl::bar;
};

int main() {
    InterfaceA<Implementation> objA;
    InterfaceB<Implementation> objB;

    objA.foo();
    objB.bar();
}

Inversion du modèle de contrat

Comme vous pouvez le comprendre, l’Implementation (Derived) n’hérite plus d’un contrat : c’est le contrat lui-même qui lui est attribué. De cette façon, la classe Implementation devient totalement indépendante et découplée de toute structure contractuelle. Cela résulte en une sorte d’inversion, où désormais autant le contrat polymorphique que l’implémentation doivent s’accommoder pour que le contrat fonctionne. C’est un peu comme si vous passiez d’une relation où il n’y a qu’une seule personne qui décide à une relation où les deux ont leur mot à dire.

Une relation contractuelle symétrique

De cette façon, nous créons une relation polymorphique contractuelle symétrique. Par exemple, si une classe Interface expose la méthode « foo », la classe implémentation se doit obligatoirement d’avoir cette méthode d’accessible, sinon le contrat ne pourra pas être validé (le compilateur va tout simplement échouer car la méthode foo n’existe pas chez Impl). D’un autre côté, la classe implémentation elle-même peut exposer d’autres méthodes hors du contrat, mais ce ne sont que les méthodes du contrat qui seront accessibles depuis l’extérieur.

Extension au multi-héritage et composition de contrats

Maintenant, il y a le sujet du multi-héritage qui devient un peu ambigu. Ce modèle est principalement pensé pour une relation 1:1 entre interface et implémentation, mais il serait aussi possible de l’étendre au multi-héritage avec un peu de prudence. Ainsi, j’ai préparé un exemple de ce à quoi ça pourrait ressembler :

#include <iostream>

template<typename... Interfaces>
struct MultiInterface : public Interfaces... {};

struct Implementation {
    void foo() { std::cout << "foo\n"; }
    void bar() { std::cout << "bar\n"; }
};

template<typename Impl>
struct InterfaceA : private Impl {
    using Impl::foo;
};

template<typename Impl>
struct InterfaceB : private Impl {
    using Impl::bar;
};

int main() {
    MultiInterface<
        InterfaceA<Implementation>,
        InterfaceB<Implementation>
    > obj;

    obj.foo();
    obj.bar();
}

Comme vous pouvez le remarquer, ça devient très lourd en lisibilité très rapidement. Il s’agirait d’utiliser des alias afin de réduire un peu la pression de ces signatures démoniaques. En ce qui concerne l’implémentation, ce n’est pas si sorcier que ça : nous utilisons un wrapper qui hérite et expose publiquement toutes les méthodes des contrats qui le forment. C’est simple et efficace, mais ce n’est pas tout à fait 100 % sécuritaire, car il y a toujours le risque que deux contrats exposent la même méthode, ce qui résulterait tout simplement en un appel ambigu.

En revanche, et je dois mettre l’emphase là-dessus, ce pattern n’est pas vraiment prévu pour une utilisation où le multi-héritage est primordial.

Applications concrètes du SIPP

Cette drôle de relation nous pousse à comprendre que cette forme de polymorphisme statique ouvre de nombreuses portes au niveau du design d’architectures orientées objet ultra performantes. Pour bien illustrer la chose, voici deux exemples très intéressants qui utilisent ce pattern.

Premier exemple : système de logging

Voici le premier exemple : il s’agit d’une simple implémentation d’un système de logging où le logger peut être vu sous deux états différents selon le contrat choisi :

#include<iostream>

struct ConsoleLogger {
    void write() {
        std::cout << "write to console\n";
    }

    void flush() {
        std::cout << "flush console\n";
    }

    void debug() {
        std::cout << "debug: console\n";
    }
};

template<typename Impl>
struct LoggingInterface : private Impl {
    using Impl::write;
    using Impl::flush;
};

template<typename Impl>
struct DebugLoggingInterface : private Impl {
    using Impl::write;
    using Impl::flush;
    using Impl::debug;
};

int main() {
    LoggingContract<ConsoleLogger> console_logger;

    console_logger.write();
    console_logger.flush();

    DebugLoggingContract<ConsoleLogger> debug_console_logger;

    debug_console_logger.debug(); // nouvelle méthode exposée
    debug_console_logger.write();
    debug_console_logger.flush();
}

Dans cet exemple, vous pouvez voir que la première vue, celle de LoggingContract, n’expose que les méthodes « write » et « flush ». Similairement, la seconde vue « DebugLoggingContract » expose les mêmes méthodes que la première, mais cette fois-ci avec l’exposition de la méthode « debug ». De cette façon, il est possible de représenter un objet de deux façons totalement différentes sans même changer son implémentation. La classe « ConsoleLogger » n’a qu’à implémenter toutes les méthodes qu’elle souhaite, et ce sont les vues/contracts qui s’occupent de l’exposition. Enfin, cela permet de garder une API propre et extrêmement extensible, vu la simplicité des contracts : il ne suffit que d’ajouter un « using Impl::ma_methode; » afin qu’elle soit maintenant exposée.

Deuxième exemple : réinterprétation de contrat et cast

Ce second exemple est un peu plus technique et pourrait être un peu plus controversé que celui d’auparavant. Il ne semble pas être le plus intéressant, mais il requiert des manipulations un peu « hacky » qui ne sont pas destinées à tous. Je ne vais pas plus tarder et je vous le montre :

#include <iostream>
#include <type_traits>

struct ConsoleLogger {
    void write() {
        std::cout << "write\n";
    }

    void flush() {
        std::cout << "flush\n";
    }

    void debug() {
        std::cout << "debug\n";
    }
};

template<typename Impl>
struct LoggingContract : private Impl {
    using Impl::write;
    using Impl::flush;
};

template<typename Impl>
struct DebugLoggingContract : private Impl {
    using Impl::write;
    using Impl::flush;
    using Impl::debug;
};

int main() {
    LoggingContract<ConsoleLogger> console_logger;

    console_logger.write();
    console_logger.flush();

    auto& debug_console_logger =
        reinterpret_cast<DebugLoggingContract<ConsoleLogger>&>(console_logger);

    debug_console_logger.debug();

    static_assert(std::is_layout_compatible_v<
        LoggingContract<ConsoleLogger>,
        DebugLoggingContract<ConsoleLogger>
    >);
}

Comme vous pouvez l’apercevoir, j’utilise un « reinterpret_cast » afin de transformer ma vue initiale utilisant « LoggingContract » en une autre vue « DebugLoggingContract ». À première vue, ça peut sembler un peu ésotérique, et ça l’est, mais il y a tout de même une certaine logique derrière cette manipulation.

Pour commencer, la question à se poser serait probablement : pourquoi est-ce que ça compile en premier lieu ? La raison est bien plus simple que vous l’imaginez, car en réalité, « LoggingContract » et « DebugLoggingContract » sont exactement la même chose en mémoire. D’ailleurs, j’ai testé à l’aide de l’utilitaire « std::is_layout_compatible_v » de la librairie standard afin d’en être certain, et le résultat fut « true ». En revanche, qui dit fonctionnel ne dit pas automatiquement sécuritaire. En effet, je vais éviter d’entrer trop dans les détails de comment l’ABI et le layout mémoire des classes fonctionnent sur la majorité des compilateurs, mais ce qu’il faut retenir, c’est qu’en mémoire, la vue (qui ne contient rien) qui hérite est exactement la même chose que sa base. Ça fonctionne très bien en pratique, mais ce n’est qu’une convention au sein de l’ABI et ce n’est pas quelque chose que le standard garantit.

En revanche, cette approche permet de transformer l'objet sans effectuer aucune opération à l'exécution, ce qui la rend quasi sans coûts. Cela permet principalement d'éviter d'avoir à effectuer une copie ou une assignation, ce qui est clairement non négligeable dans des projets où les performances sont critiques. C'est un coût à payer et c'est à vous de voir s'il convient à votre situation.

Outre tous ces malheureux détails, ce cast permet principalement de réinterpréter la vue d’un objet sans en changer sa nature. En fait, le « debug_console_logger » issu du « reinterpret_cast » pointe sur l’exact même objet que la vue « LoggingContract » originale pointait. Tout cela signifie que nous pouvons réinterpréter le contrat polymorphique d’un objet à la compilation, et je trouve ça extrêmement intéressant.

Troisième exemple : conversion sécuritaire entre vues

Ce troisième et dernier exemple est destiné à adresser les problèmes de sécurité du dernier exemple. En effet, je n'ai pas voulu placer cet exemple avant l'autre, car il traite de techniques un peu différentes que le pattern de base. Je vous montre :

#include <iostream>
#include <type_traits>

struct ConsoleLogger {
    ConsoleLogger() = default;

    ConsoleLogger& operator=(const ConsoleLogger& other) {
        return *this;
    }

    void write() {
        std::cout << "write\n";
    }

    void flush() {
        std::cout << "flush\n";
    }

    void debug() {
        std::cout << "debug\n";
    }
};

template<typename Impl>
struct LoggingContract : private Impl {
    explicit LoggingContract(Impl& m) : Impl(m) {} // afin d'assigner la base à la création

    using Impl::Impl;

    using Impl::write;
    using Impl::flush;
};

template<typename Impl>
struct DebugLoggingContract : private Impl {
    explicit DebugLoggingContract(Impl& m) : Impl(m) {} 

    using Impl::Impl;

    using Impl::write;
    using Impl::flush;
    using Impl::debug;
};

int main() {
    ConsoleLogger console_logger_impl;

    LoggingContract<ConsoleLogger> console_logger{ console_logger_impl }; // il supporte la construction à l'aide du type de l'implémentation

    console_logger.write();
    console_logger.flush();

    DebugLoggingContract<ConsoleLogger> debug_console_logger;

    debug_console_logger = console_logger_impl; // il supporte aussi l'assignation du type de l'implémentation

    debug_console_logger.debug();
}

Comme vous pouvez l'apercevoir, cette version a, elle aussi, comme principal but de permettre l'assignation d'un objet à différentes vues. Elle le fait en utilisant un constructeur de délégation se situant dans la vue et qui lui permet de recevoir un objet du type 'Impl' afin de l'assigner en tant que base. De plus, elle expose les méthodes spécifiques de l'implémentation avec 'using Impl::Impl', qui, dans notre exemple ici, permet d'exposer l'opérateur d'assignation.

Il faut savoir que le mécanisme utilisé ici est totalement sécuritaire et prévu par le langage. Cependant, bien qu'il semble être une meilleure option que le dernier exemple, il présente tout de même un très gros problème : le coût en performance. Effectivement, le passage de paramètres par constructeur et l'utilisation de l'opérateur d'assignation ajoutent un coût supplémentaire lors de l'exécution du programme. De ce fait, ce n'est pas la fin du monde, mais dans le contexte d'un système où ce patron est massivement utilisé, ça pourrait commencer à coûter très cher. Enfin, il apporte aussi un certain coût en complexité et en lisibilité, ce qui n'est pas négligeable, car les éléments ajoutés dans cette version seront présents dans chacune des vues et des implémentations du système.

Conclusion finale

Pour conclure, je souhaiterais adresser quelques mots aux personnes qui se sont rendues jusqu’ici dans l’article. Déjà, merci d’avoir lu mon travail, j’en suis extrêmement reconnaissant.

Ensuite, je dois vraiment mettre au clair que je ne prétends pas avoir inventé un pattern. Je ne fais que mettre en lumière une variation très intéressante de choses qui existent déjà. D’ailleurs, j’avais aussi comme objectif de donner un nom à cette technique, et je ne sais pas vraiment comment la communauté C++ réagit à ce genre de choses, mais je le fais avec de bonnes motivations.

Je vois de l’avenir dans ce pattern et je crois vraiment qu’il y a quelque chose de vraiment plus grand à en tirer. Bon, c’est ainsi que se termine mon second article à vie. Il fut beaucoup moins technique que mon premier, et c’était intentionnel. Vulgariser est un art, et il est la clé de l’apprentissage.

Ressources et lecture complémentaire

Article sur l'exotic CRTP : https://medium.com/@felixolivierdumas/exotic-crtp-repenser-le-polymorphisme-statique-avec-c-23-bb09cc096f5b
Explorer le code de l’exotic CRTP : https://github.com/unrays/exotic-crtp

Exotic CRTP: Enforcing Access-Controlled CRTP with C++23 Explicit Object Parameters

Félix-Olivier Dumas — Thu, 11 Jun 2026 15:25:09 +0000

Polymorphism, Rethought at Compile-Time

In this article, we will explain how the features of C++23 are revolutionizing the philosophy of static polymorphism. We will also take this opportunity to give you an exclusive look at a new pattern inspired by the latest discoveries in the field.

Origins and History of the CRTP

First of all, it would be relevant to clarify what the Curiously Recurring Template Pattern (CRTP), or commonly called CRTP, is. CRTP is a technique that consists of simulating the behavior of virtual polymorphism exclusively at compile-time.

This technique was formalized in 1989 under the name F-bounded polymorphism. The term CRTP was independently coined by Jim Coplien in 1995 after he observed it multiple times in different codebases of that era.

Technically speaking, its operation relies on passing the derived type to the base via a template in order to enable a mechanism called "static downcasting."

In the context of CRTP, this mechanism consists in the base statically "casting" itself to the derived type passed through the template, which allows it to "transform" into it and access its members.

This "downcast" mechanism is possible thanks to the inheritance relationship that the derived type maintains with the base. In this way, the base can act as an entry point to the derived type's methods, thereby simulating a polymorphic behavior strictly evaluated at compile-time..

#include <iostream>

template <typename Derived>
class Base {
public:
    void interface() {
        // Calls the method implemented in the derived class
        static_cast<Derived*>(this)->implementation();
    }
};

class Derived : public Base<Derived> {
public:
    void implementation() {
        std::cout << "Derived implementation" << std::endl;
    }
};

int main() {
    Derived d;
    d.interface(); // Calls Derived::implementation()
    return 0;
}

Why Sacrifice Simplicity for Performance?

Now, a question arises: why use this technique if it seems to do the same thing as virtual polymorphism, but in an unnecessarily complex way?

This is a legitimate question, and the answer is just as legitimate. The CRTP is primarily used because of the flexibility and performance gains it provides. Indeed, since the polymorphic relationship is strictly evaluated at compile-time, it costs practically nothing during execution.

More precisely, the cost of a call is practically zero because it does not use any "vtable", unlike dynamic polymorphism. The use of a "vtable" has many advantages, but it still introduces a slight overhead. This overhead is often imperceptible, but it is absolutely non-negotiable in certain systems where performance is critical.

Under certain conditions, it is even possible to inline calls from the base, which allows one to achieve the maximum attainable performance. According to calculations carried out by Eli Bendersky, an architecture based on static polymorphism is on average faster than one using its dynamic counterpart. Besides, I strongly invite you to read his article "The Cost of Dynamic Virtual Calls vs. Static CRTP Dispatch in C++" if you want to learn a little more about the gains of CRTP. It is extremely comprehensive, and I personally found it very interesting.

As I vaguely mentioned earlier, the Curiously Recurring Template Pattern is a fundamental building block in many environments where performance is critical and every CPU cycle counts.

It is mainly found in areas such as high-frequency trading, game engines, or embedded applications. These environments rely on speed, and CRTP is a particularly well-suited tool for these purposes.

The Costs and Limitations of Static Polymorphism

Now, let's be realistic for a moment: these gains are clearly not free. Indeed, the CRTP introduces many issues and limitations that can quickly turn into a nightmare for the system and the programmers working on it. Among these issues, we often find three main ones that we will address in the next segment.

Problem 1: Violation of Encapsulation Control

First of all, one of the biggest issues, from an architectural and security standpoint, is that the base has constant and unrestricted access to the public members of the derived class. Concretely, this absence of access restriction exposes the derived object to side effects or dangerous uses that can quickly compromise its integrity.

The main problem here concerns the control of encapsulation, because the base should not touch everything the derived class does. Moreover, as if that were not enough, the base theoretically has access to the very instance of the derived class, which introduces serious risks regarding the instance itself.

Thus, since all public methods of the derived class are accessible from anywhere, including from the base or from other code holding a Derived*, there is no real notion of polymorphic exclusivity within the CRTP.

template <typename Derived>
class Base {
public:
    void interface() {
        // Even if Derived exposes nothing,
        // Base can access everything that is private
        static_cast<Derived*>(this)->secret_value;
    }
};

class Derived : public Base<Derived> {
    friend Base<Derived>;
private:
    void* secret_value;
};

Problem 2: Inability to Hide Derived Methods

Another limitation of the CRTP is that it does not allow hiding methods of the derived class, unlike dynamic polymorphism which fundamentally includes it. This is not a limitation of the concept itself, but a side effect of how it works.

Indeed, since the base uses a form of the derived object, it can only execute what the object exposes publicly. In this way, the derived class must expose its implementation publicly so that the base can call it… which literally contradicts the very principle of polymorphism.

Furthermore, as if that were not enough, since the derived class exposes publicly both its implementations and those of the base it inherits from, it ends up duplicating each of its functionalities.

Consequently, many solutions have been proposed and adopted over the evolution of the CRTP, and some have become widespread. One of them consists in making the derived class's implementations private and declaring the base as friend, which roughly amounts to granting the base access to all private members of the derived class.

Fundamentally, this approach is totally legitimate and even mandatory in certain situations, but it remains very dangerous and conceptually dirty. I will come back to this later with a much more natural and logical approach.

template <typename Derived>
class Base {
public:
    void interface() {
        // Calls the private method implemented in the derived class
        static_cast<Derived*>(this)->implementation();
    }
};

class Derived : public Base<Derived> {
    friend Base<Derived>;
private:
    void implementation() {
        std::cout << "Private implementation of Derived" << std::endl;
    }
};

Problem 3: Complexity and Readability

In this way, the CRTP presents a fairly obvious problem at first glance: low readability and code complexity. This is not surprising, because its implementation relies on concepts that are individually already very hard to read, and when combined, make the experience unpleasant for any developer venturing into it.

Templates, casting, dense logic, friend, invariants, it's technically very dense for something that is supposed to be repeated throughout an architecture.

For example, as I vaguely mentioned earlier, the hiding of derived members using private and friend, which is found in many implementations, is extremely redundant and verbose.

Furthermore, it is this astronomical amount of redundancy that justifies the next segment of this article.

C++23 and the Arrival of Deducing This

Now that you understand the stakes surrounding this legendary technique, it is time to address why this article exists in the first place.

In the next section, we will discuss a feature very recently introduced in C++23 that opens new possibilities in the implementation of static polymorphism.

First of all, it is important to contextualize everything in order to properly grasp the essence of the following sections. C++23 is the latest major revision of the ISO standard of the C++ language. It was finalized in 2023 by the ISO WG21 standardization committee and is slowly becoming mainstream at the time I am writing this article.

Unlike C++20, which introduced major features such as concepts, ranges, or coroutines, C++23 looks more like an evolution than a revolution. Among the new features it brings, we find "if consteval", std::expected, improvements to std::format, deducing this, and many others.

Today, it is this last feature, deducing this, that interests us. Indeed, deducing this (Explicit Object Parameter, proposal P0847) is a feature proposed by Gašper Ažman, Sy Brand, Ben Deane, and Barry Revzin, which allows making the implicit this parameter of a member function explicit, enabling its deduction via templates. This parameter must be the first, preceded by the keyword this, and represent the type of the object.

#include <iostream>

struct Counter {
    int value = 0;

    void increment(this Counter& self) {
        self.value++; // increments the counter by 1
    }

    void show(this const Counter& self) const {
        std::cout << self.value << "\n"; // displays the current value
    }
};

int main() {
    Counter c;
    c.increment();  // self is automatically the Counter c
    c.increment();
    c.show();       // displays: 2
}

New Possibilities for Static Polymorphism

This feature is not only revolutionary, but it also allows deduction using templates and can serve as an execution policy for a member function. I will come back to this last point a little later.

At this point, you are probably wondering what the connection is with the CRTP discussed earlier. I think a simple piece of code is enough to understand what deducing this brings to CRTP.

struct Base {
    void interface(this auto&& self) {
        // self is automatically deduced as the correct derived type,
        // no static_cast is needed
        self.implementation();
    }
};

struct Derived : Base {
    void implementation() {
        std::cout << "Derived implementation" << std::endl;
    }
};

Comparison with Traditional CRTP

As you have probably noticed, there is no contest between the two implementations. In this way, we will compare them in order to draw conclusions that will smoothly guide us toward the next section.

First, what immediately stands out is the total absence of templates at the base level. Indeed, if you remember well, passing the derived type allows the base to statically know the actual type to perform a safe downcast.

Now, since we can explicitly declare the implicit this parameter of the caller function, this means that the member function receives the calling object directly with its exact type at each call, removing the need to pass the derived type at compile-time. This change drastically improves readability and makes the implementation almost identical to that of virtual inheritance.

Furthermore, you can also notice that the static cast has been replaced by a member call from the explicit parameter. Again, this is not surprising: since we receive the calling object with its exact type at the call, it is sufficient to use it to exercise polymorphic delegation.

In this way, the code is simplified to its most readable and logical form. This is a very big advantage compared to the old technique, which relied on a downcasting system that was very fragile and unsafe.

The Persistent Encapsulation Problem

However, beyond these notable changes in simplicity and readability, we are left with the same problem as before. More specifically, if you look closely, both implementations present no difference regarding access to the members of the derived class.

Here, the solution could be to implement the good old pattern where methods are set to private and the base is added as friend in the derived class. This would work perfectly and is a totally valid approach.

However, look at what happens to the readability of the class once there is more than a single CRTP inheritance in the same derived class.

// Base template using CRTP
template <typename Derived>
struct Base {
    void interface() {
        static_cast<Derived*>(this)->implementation(); // calls the private implementation of Derived
    }
};

// Five different CRTP bases
template <typename Derived> struct Base1 : Base<Derived> {};
template <typename Derived> struct Base2 : Base<Derived> {};
template <typename Derived> struct Base3 : Base<Derived> {};
template <typename Derived> struct Base4 : Base<Derived> {};
template <typename Derived> struct Base5 : Base<Derived> {};

// Derived class inheriting from the 5 CRTP bases
class Derived : public Base1<Derived>, public Base2<Derived>,
                public Base3<Derived>, public Base4<Derived>,
                public Base5<Derived> 
{
    // Grant friendship to all bases to access private members
    friend Base1<Derived>;
    friend Base2<Derived>;
    friend Base3<Derived>;
    friend Base4<Derived>;
    friend Base5<Derived>;

private:
    void implementation() {
        std::cout << "Private implementation of Derived\n"; // private method called by the bases
    }
};

You now understand that, although the readability of modern CRTP is light-years ahead of the old one, the issue of access and encapsulation still persists. The next question arises: would you be willing to sacrifice the readability of your classes for the security and encapsulation of the derived class?

Readability or Encapsulation?

Personally, I have always tended to not really know which approach to choose. As a result, I often yield out of insecurity and end up with classes full of friend and private members. If only there were a way to reach a middle ground, where one could maintain security without necessarily losing readability!

And what if I told you that there is a solution…!

Exotic CRTP: An experimental Approach

To this end, I have extensively experimented with these new features over the past few days and discovered something extremely interesting. Here is the result of my experiments in this area.

namespace exotic {
    template<typename From>
    struct crtp_access : From {};

    template<typename T>
    constexpr decltype(auto) as_crtp(T&& obj) noexcept {
        using crtp_access_t = crtp_access<std::remove_cvref_t<T>>;
        return static_cast<crtp_access_t&&>(obj);
    }
}

struct Base {
    void interface(this auto&& self) {
        exotic::as_crtp(self).implementation();
    }
};

struct Derived : Base {
    void implementation(this exotic::crtp_access<Derived> self) {
        std::cout << "Derived implementation" << std::endl;
    }
};

Understanding the Pattern

At first glance, this may seem a bit incomprehensible, but we will gradually go through each aspect of this code in order to better understand it.

Moreover, I have also named this pattern "exotic CRTP", following the convention I apply across all of my projects. It is a rather original approach, and the code reflects this "exotic" nature quite well.

Unlike the previously presented approaches, this one relies on a multitude of concepts that enable a very particular form of access control. I will come back to this.

More precisely, if you observe carefully, you will notice that the base method receives the explicit this object as a parameter (deducing this). In this way, when we call the base method from the derived class, we receive it as a parameter on which we can perform some subtle manipulations.

Without going too deep into details for now, you can keep in mind that these manipulations are performed using a generic utility named as_crtp. This utility has the sole purpose of pseudo-transforming the object it receives into a wrapper named crtp_access. This crtp_access is essentially intended to act as a proxy between the restricted methods of the derived class and those of the base. Furthermore, this wrapper is defined using template arguments from which it will inherit.

The Transformation Mechanism

First of all, I must address the elephant in the room and make it clear that the manipulations performed on the objects are somewhat borderline and hacky. But wait a moment, do not leave just yet, as I must explain the very specific reasons behind this controversial choice.

To begin with, it is necessary to understand certain key concepts in order to grasp the mechanism being used. In C++, code is compiled by tools known as compilers. Each compiler's main goal is to produce output that conforms as closely as possible to the language standard rules. Therefore, although they generally produce similar results, this does not necessarily mean that they all operate in the same way. This internal behavior, unique to each compiler and existing as an intermediate contract, is called the ABI (Application Binary Interface).

Now that we have a better understanding of what an ABI is, we can discuss some subtleties of the language. In most C++ ABIs, the memory layout of classes/structs remains roughly similar. This is not required by the standard, but it is a common convention.

The layout is as follows: the first address of our object is reserved for its base classes. Here, we will focus on inheritance without virtual polymorphism, as it drastically changes the layout behavior. Thus, we always find the base classes first, followed by the derived object. Why is this done, you may ask? It is simply for ease of memory transformation when dealing with statically inherited classes (upcasting/downcasting).

Concretely, if you have an 8-byte base and an 8-byte derived class, the layout will be as follows:

┌─────────────────┐       ┌────────────────────┐ 
│ Base : 8 bytes  │  -->  │ Derived : 8 bytes  │
└─────────────────┘       └────────────────────┘

Next, we must understand one final and very important C++ subtlety: the "non-zero object size rule". The standard guarantees that the size of a class/struct is always greater than 0. This simply means that a completely empty class/struct will have a size of 1 byte.

At this point, you might think that if an empty derived class inherits from an 8-byte base, its total size would be 9 bytes? Wrong, it will be 8 bytes, because the standard guarantees this minimum only in cases where the size would otherwise be 0. Therefore, you are now starting to understand: our empty derived class inherits from the base and has exactly the same memory representation as it.

struct Base { 
  int a; // 4 bytes
};

struct Derived : Base {}; // empty

sizeof(Derived) == sizeof(Base) -> true

The shared memory representation principle

This is precisely what makes the transformation mechanism of the previously described CRTP pattern work. If you look closely, the manipulation begins with the definition of a type alias named crtp_access_t. This defines the type crtp_access, where T represents the type of the passed parameter (the derived type in our case).

using crtp_access_t = crtp_access<std::remove_cvref_t<T>>;
return static_cast<crtp_access_t&&>(obj);

As you may recall, we previously defined that the crtp_access wrapper inherits from each of the template arguments it receives. Therefore, the resulting type would look something like this:

struct crtp_access : Derived {}; // equivalent to crtp_access<Derived>

In practice, as previously discussed, since the crtp_access class is empty and inherits from a base class, its memory representation is virtually identical to that of Derived itself. This is a very interesting and important detail for what follows.

The non-conventional cast and its implications

From this observation, you may notice that the next line is somewhat unusual. Indeed, it performs the "forbidden" manipulation that makes this CRTP pattern possible.

Let me explain: we transform, using a static_cast, the received derived object into crtp_access. First, let us explain why this is considered forbidden. It is forbidden because we are performing a pseudo-upcast from a Derived type into a type it does not actually inherit from.

The cast works for reasons I will explain later, but it is important to understand that it fundamentally breaks the object representation model in C++. However, it still works because, as you may recall, in most ABIs, the crtp_access wrapper is nearly identical to Derived itself. Therefore, when we static_cast a Derived into crtp_access, it is essentially equivalent to casting Derived to Derived.

static_cast<crtp_access<Derived>>(d)  ≡  static_cast<Derived>(d)
// same memory layout (no copy, no reordering)

Moreover, this cast primarily serves to transform the Derived object into a crtp_access type without performing any instantiation or costly copy. The casted Derived object then becomes the base object of crtp_access, allowing it to access all methods and members of Derived.

That being said, we understand that this is a hack that works but is not guaranteed by the language. I must emphasize again: this pattern is experimental and intended as a technical and architectural demonstration rather than something to be used in production.

Once this transformation is performed, the as_crtp utility returns the wrapped type to the base method, and the base method then calls the implementation() method on the crtp_access object as if it were the original Derived object itself.

We therefore obtain, although illegal, a mechanism that allows an object to be transformed into another type without changing its behavior.

This delegation is extremely important for the next step, you will soon understand why.

Restricting Access to Implementations

From here, it is interesting to look at the implementation of the derived class. You can observe that the implementation() method has the argument this crtp_access self. This implicit this parameter acts as an execution policy for the concerned method.

void implementation(this crtp_access<Derived> self)

Specifically, this annotation means that the only object able to see and call the concerned method is a crtp_access. In this way, the derived object can neither see nor call this method as it does not satisfy the explicit this parameter condition of the function.

This means that, ultimately, the only class able to see and call this method is the one resulting from as_crtp executed by the base.

By doing this, we simulate the behavior of a private implementation while keeping the method public, which completely matches the solution we were looking for.

struct Derived : Base {
    void implementation(this crtp_access<Derived> self) {
        std::cout << "Derived implementation" << std::endl;
    }
};

int main() {
    Derived d;
    // d.implementation(); // Impossible: not publicly accessible
    d.interface();         // Allowed call via the base
    // From the object "d", only .interface() is visible
    // d. <-- the IDE will only propose .interface() and other public Base/Derived methods
    return 0;
}

Advantages of This New Approach

Now, let us address the advantages that this approach brings compared to the different CRTP models previously explored in this article.

On one hand, it massively reduces the boilerplate normally found. Indeed, the use of crtp_access eliminates the need for friend and private in favor of an approach without real compromise.

Thus, it is possible to enjoy pseudo-private encapsulation of derived methods while favoring code extensibility and maintainability.

Polymorphic Control at the Method Level

Furthermore, this approach also allows individualizing polymorphic management for each derived method.

Indeed, since this crtp_access self grants exclusivity of access and visibility to the function, it is possible to use it to "activate" or "deactivate" the polymorphic behavior by removing it.

struct Derived : Base {
    void implementation(this crtp_access<Derived> self) { ... } // restricted access

    void implementation() { ... } // public access
};

For example, if we decide to remove this crtp_access self, the method loses its polymorphic exclusivity and becomes publicly visible and accessible.

Personally, I find this extremely interesting because it reminds me of the behavior of override found more traditionally in virtual polymorphism. At least, it resembles it, because in our case, if we remove this crtp_access self, the method is still visible and callable from the base.

However, it would be totally possible and justified to implement an extension that detects if the function contains the restriction parameter.

Encapsulation Without Friend

Finally, this approach offers a level of security and encapsulation that others cannot provide.

Specifically, previous techniques often used a mix of friend + private. This mix, although very useful, directly exposes the derived's private members to the base. This exposure using friend breaks the principle of encapsulation and often ends up becoming more of a hack than anything else.

Fortunately, the exotic approach completely eliminates this problem because it does not use friend to restrict the visibility of the implementation.

Indirect Interaction with the Derived

Moreover, as you may recall, we previously discussed that CRTP had the unfortunate tendency to interact directly with the derived. More specifically, this concerns the original implementation using static_cast.

This is precisely what the proposed approach changes because the base never interacts directly with the derived. Indeed, the derived's implementation methods are only accessible through a crtp_access, which forces the base to use it to call the desired methods.

struct Base {
    void interface(this auto&& self) {
        as_crtp(self).implementation();
    }
};

Thus, the crtp_access acts as a proxy for the members explicitly concerned by polymorphic interaction. Moreover, it is also possible to specify several template members inside the crtp_access, allowing the creation of a kind of "variant-crtp", where a derived can exist in two different forms at the same time.

A Simple and Natural API

Finally, usability from the API remains considerably identical to the previously discussed approaches. In fact, it seems to perfectly align with the different variations of CRTP found throughout its evolution.

The as_crtp is presently just an encapsulation detail that I preferred to add, but it would be totally possible for you to implement the method in the way you like.

The drawbacks of this approach

Now that we have covered the advantages of the pattern, it is time to address what likely prevents this pattern from being used in very strict environments.

As you may have already noticed, we are performing a manipulation that simply breaks the language's object memory representation rules. Moreover, even though we are using a static_cast instead of a reinterpret_cast, and everything seems to compile, it still remains that, in theory, this is absolutely not guaranteed by the standard.

When we refer to a behavior that is not guaranteed by the standard, we call it UB (Undefined Behavior). In our case, this UB does not cause any crash or corruption, because the system is carefully implemented in a way that keeps operations safe.

However, it is important to keep in mind that its behavior relies on an unofficial convention of modern C++ ABIs, and that if the memory layout model of classes/structs were ever to change (which I highly doubt), it could stop working entirely.

As a comparison, we could think of this as using a product in a way that goes against its intended usage: you will definitely lose the warranty and you will no longer receive customer support, but that does not necessarily mean the product is broken. It simply will no longer be covered by the warranty, you are on your own.

Personally, I like this analogy, because it reflects very well the convictions I had. I will explain this a bit later, but this was the only possible solution that allowed me to achieve the result I was aiming for.

Analysis of alternatives

Finally, I think it is relevant to show some of the many options I considered and which, due to lack of success, led me to the version I currently have.

Attempt 1

First, I tried to make the transformation from Derived into crtp_access safe by making Derived inherit from crtp_access_policy(crtp_access).

namespace exotic {
    template<typename From>
    struct crtp_access_policy: From {};

    template<typename T>
    constexpr decltype(auto) as_crtp(T&& obj) noexcept {
        using crtp_access_t = crtp_access_policy<std::remove_cvref_t<T>>;
        return static_cast<crtp_access_t&&>(obj);
    }
}

struct Base {
    void interface(this auto&& self) {
        exotic::as_crtp(self).implementation();
    }
};

struct Derived : exotic::crtp_access_policy<Derived>, Base {
    void implementation(this exotic::crtp_access_policy<Derived> self) {
        std::cout << "Derived implementation" << std::endl;
    }
};

However, the problem was quickly identified: by making Derived inherit from crtp_access_policy, which itself inherits from Derived, we create a cyclic inheritance loop, which is forbidden by the standard.

Furthermore, since Derived is now composed with a crtp_access_policy base, the implementation function using the Explicit Object Parameter to restrict access can no longer work properly.

Why? Simply because Derived, being intrinsically a crtp_access_policy, is implicitly upcast to crtp_access_policy when calling the method, making it callable from within Derived itself.

Attempt 2

Next, I tried to completely change how the derived type is transformed in order to make it safe. In short, I attempted to make crtp_access_policy no longer inherit from Derived, but instead store it by reference.

namespace exotic {
    template<typename Tp>
    struct crtp_access_policy {
        crtp_access_policy(Tp& p_obj) : obj(p_obj) {}
        Tp& obj;
    };
}

struct Base {
    template<typename Self>
    void interface(this Self&& self) {
        auto& accessor = reinterpret_cast<
            exotic::crtp_access_policy<std::decay_t<Self>>&
        >(self);

        using DerivedType = std::decay_t<Self>;
        std::invoke(&DerivedType::implementation, accessor);
    }
};

struct Derived : private exotic::crtp_access_policy<Derived>, Base {
    Derived() : exotic::crtp_access_policy<Derived>(*this) {}

    void implementation(this exotic::crtp_access_policy<Derived>& accessor) {
        std::cout << "Derived implementation" << std::endl;

        Derived& derived = accessor.obj;
    }
};

As we can see, since crtp_access_policy no longer inherits from Derived, Derived can now safely inherit from it. Additionally, the inheritance must be private in order to prevent implicit conversions from Derived to the CRTP wrapper.

Then, in the base, we use a reinterpret_cast (because the inheritance is private) to upcast Derived into crtp_access_policy in order to execute the restricted implementation method of Derived.

After this operation, inside the method, we can recover the Derived object using Derived& d = accessor.obj, and everything works.

Unfortunately, the issue with this approach is that it is extremely heavy in complexity for what it tries to achieve. Its goal is to make the code more readable, not more complex to understand.

Furthermore, since Derived is intrinsically always a crtp_access_policy, the method still appears in autocompletion, and strange conversion issues occur. Sometimes it is possible to call the restricted method, sometimes not.

To eliminate this ambiguity, one would need to explicitly delete conversion operators in Derived, but at that point, it is no longer really worth continuing.

For all these reasons, the cleanest and simplest solution is the one I present today.

It is not perfect, and not everyone is willing to use something that is not guaranteed by the standard, but for the gains in readability and design it provides, I am willing to overlook these details for now.

Conclusion

To conclude, it seems important to provide a brief summary of what has been covered in this article. First, we discussed the concept of CRTP and its evolution throughout history. This rapid evolution was marked by numerous revolutions, including the one brought by the latest C++23 standard. This standard contains a feature, deducing this, which completely changes the way CRTP is implemented. It brings readability and simplicity, but still does not solve the boilerplate problems that plagued its predecessor.

Knowing this, the question was posed: is there a solution allowing readability and extensibility without compromise? Fortunately, after numerous experiments, a result seemingly addressing these issues presented itself. This result, which I affectionately named "exotic crtp", proved to be the perfect solution to the problems that CRTP had imposed on me before.

A perfect solution? I absolutely do not believe so! However, what I do know for sure is that I wrote this article with passion and learned a great deal about the subject over the past few days. It was a wonderful journey - who knows, will anyone ever hear about my work? Who knows, for now, I wish you a very pleasant end of the day. Thank you for dedicating your precious time to my article, I am infinitely grateful.

To Go Further

Explore the exotic CRTP code: https://github.com/unrays/exotic-crtp
Read about a project I worked on: Anatomy of an LLVM Compiler Built from Scratch
Dynamic vs. static CRTP comparison: Eli Bendersky

Source: “Studying with computer and book”, Adobe Stock

DEV Community: Félix-Olivier Dumas

Static Interface Projection Pattern (SIPP): Static Control of Method Exposure in C++

Introduction and context

Understanding polymorphism

Static Polymorphism in C++

Analysis of the CRTP Example

Advantages of Static Polymorphism

Limitations and Drawbacks

Code Complexity and Readability

Slicing and Storage Issues

Exposure of Implementation Methods

Interim Conclusion

SIPP: an Experimental Approach to Static Polymorphism

Pattern Overview

Understanding How SIPP Works

Inversion of the Contract Model

A Symmetrical Contractual Relationship

Extension to Multiple Inheritance and Contract Composition

Practical Applications of SIPP

First Example: Logging System

Second Example: Contract Reinterpretation and Cast

Third Example: Safe Conversion Between Views

Final Conclusion

Further Reading and Resources

[Boost]

Static Interface Projection Pattern (SIPP) : contrôle statique de l’exposition des méthodes en C++

Static Interface Projection Pattern (SIPP) : contrôle statique de l’exposition des méthodes en C++

Introduction et contexte

Comprendre le polymorphisme

Le polymorphisme statique en C++

Analyse de l’exemple CRTP

Avantages du polymorphisme statique

Limites et désavantages

Complexité et lisibilité du code

Problèmes de slicing et de stockage

Exposition des méthodes d’implémentation

Conclusion intermédiaire

SIPP : une approche expérimentale du polymorphisme statique

Présentation du pattern

Comprendre le fonctionnement du SIPP

Inversion du modèle de contrat

Une relation contractuelle symétrique

Extension au multi-héritage et composition de contrats

Applications concrètes du SIPP

Premier exemple : système de logging

Deuxième exemple : réinterprétation de contrat et cast

Troisième exemple : conversion sécuritaire entre vues

Conclusion finale

Ressources et lecture complémentaire

Exotic CRTP: Enforcing Access-Controlled CRTP with C++23 Explicit Object Parameters

Polymorphism, Rethought at Compile-Time

Origins and History of the CRTP

Why Sacrifice Simplicity for Performance?

The Costs and Limitations of Static Polymorphism

Problem 1: Violation of Encapsulation Control

Problem 2: Inability to Hide Derived Methods

Problem 3: Complexity and Readability

C++23 and the Arrival of Deducing This

New Possibilities for Static Polymorphism

Comparison with Traditional CRTP

The Persistent Encapsulation Problem

Readability or Encapsulation?

Exotic CRTP: An experimental Approach

Understanding the Pattern

The Transformation Mechanism

The shared memory representation principle

The non-conventional cast and its implications

Restricting Access to Implementations

Advantages of This New Approach

Polymorphic Control at the Method Level

Encapsulation Without Friend

Indirect Interaction with the Derived

A Simple and Natural API

The drawbacks of this approach

Analysis of alternatives

Attempt 1

Attempt 2

Conclusion

To Go Further