Click here to Skip to main content
Click here to Skip to main content

C++: Prefer Curiously Recurring Template Pattern (CRTP) to Template Pattern

, 31 Jan 2013
Rate this:
Please Sign up or sign in to vote.

Introduction

The Template Pattern defined in the GoF Design Patterns book, is unrelated to C++ templates and is a behavioral pattern. The Curiously Recurring Template Pattern (CRTP) is improvement on the Template Pattern and is a C++ idiom in which a class X derives from a class template instantiation using X itself as template argument. The name of this idiom was coined by Jim Coplien, who had observed it in some of the earliest C++ template code. This technique achieves a similar effect to the use of virtual functions, without the costs (and some flexibility) of dynamic polymorphism. CRTP can be used in place of Template Pattern, provided that dynamic polymorphism is not required at runtime. This pattern is used extensively in the Windows ATL and WTL libraries.

Template Pattern

Let us look at the vanilla Template Pattern first. The Template Pattern makes use of polymorphism and a template method to do its work. In our example, the abstract base class, AbstractTextout, has 11 overloaded Print functions and a pure virtual function, Process which is only implemented in the derived class. Examples of possible useful derived class could be logging, console output and debug printing. Only debug printing class is implemented.

class AbstractTextout
{
public:
    void Print(const wchar_t* fmt);
    // ... plus 10 other overloaded Print with different number of Box arguments
protected:
    virtual void Process(const std::wstring& str) = 0;
};

The code for one of the Print functions is shown below. Box argument is responsible for converting the POD to string. The difference with the rest of the overloaded Print functions are just pushing back more Box arguments into the vs. I would not cover the Box class as it is not focus of this tip/trick. Reader may download the source code from the tip.

void AbstractTextout::Print(const wchar_t* fmt, Box D1)
{
    std::wstring wsfmtstr = fmt;

    std::vector<std::wstring> vs;
    vs.push_back( D1.ToString() );

    std::wstring str = StrReplace( wsfmtstr, vs );

    Process(str); // implemented in the derived class only.
}

This is how the derived class, DebugPrint, implemented the Process function in DebugPrint.cpp.

void Process(const std::wstring& str)
{
#ifdef _DEBUG
    OutputDebugStringW( str.c_str() );
#endif
}

This is how DebugPrint class is used.

#include "DebugPrint.h"

void main()
{
    DebugPrint dp;

    dp.Print(L"Product:{0}, Qty:{1}, Price is ${2}\n", L"Shampoo", 1200, 2.65);
    // display "Product:Shampoo, Qty:1200, Price is $2.650000"
}

A vtbl is implemented for class with virtual functions. There is overhead of the vtbl to determine the correct function to call. Curiously Recurring Template Pattern is using static polymorphism to eliminate this overhead. Let us see how it is achieved in the following section.

Curiously Recurring Template Pattern

AbstractTextout is now a template class which means all the code defined in the cpp, have to move to the header file. Before calling Process, the code will cast itself to the derived type first.

template <typename Derived> 
class AbstractTextout
{
public:
    void Print(const wchar_t* fmt, Box D1 )
    {
        std::wstring wsfmtstr = fmt;

        std::vector<std::wstring> vs;
        vs.push_back( D1.ToString() );

        std::wstring str = StrReplace( wsfmtstr, vs );

        static_cast<Derived*>(this)->Process(str);
    }
}

DebugPrint is unchanged, except itself is a template type in its base class, AbstractTextout and I have to make Process non-virtual and move it to header file.

class DebugPrint : public AbstractTextout<DebugPrint>
{
public:
    void Process(const std::wstring& str)
    {
#ifdef _DEBUG
        OutputDebugStringW( str.c_str() );
#endif
    }
};

Usage of DebugPrint class remains unchanged.

#include "DebugPrint.h"

void main()
{
    DebugPrint dp;

    dp.Print(L"Product:{0}, Qty:{1}, Price is ${2}\n", L"Shampoo", 1200, 2.65);
    // display "Product:Shampoo, Qty:1200, Price is $2.650000"
}

Related Links

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

SV Wong
Software Developer
Singapore Singapore

Currently into areas like 3D graphics and application security. Hoping to revisit the cryptography and design pattern topics if time permits.


Comments and Discussions

 
QuestionSelf documented code PinmemberKawazoe Masahiro1-Feb-13 5:46 
I have been using this pattern for a long time and, if there is no need to polymorphism, it can save you some performance headaches in thigh systems. There is only one issue with this pattern that bothers me and I still fail to find a good way to fix it. Declaring an abstract method does not only ask the compiler to handle a vtable. It also mean something to the developers who will use that class. It tells them that there is a behavior that need to be implemented explicitly in their derived types. It also tells them what this behavior is through the method name and parameters.
 
The problem with the CRTP is that there is no way (that I have found yet) to properly document this behavior in the template base class. A user of this class have to read the entire implementation to properly understand what needs to me implemented in the derived types. That is, assuming that there is no extra documentation. Have you thought about this problem, and if so, have you found a way to illustrate this concept clearly?
 
Aside from always providing a dummy default implementation, nothing comes in my mind...
GeneralMy vote of 5 PinmemberPony27931-Jan-13 19:46 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web04 | 2.8.140721.1 | Last Updated 31 Jan 2013
Article Copyright 2013 by SV Wong
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid