C++ Core Guidelines: Rules for Template Metaprogramming

Yes, you read it correctly. Today, I write about template metaprogramming, programming with types and not values. 

The introduction to template metaprogramming in the guidelines ends uniquely: "The syntax and techniques needed are pretty horrendous.". In accordance, the rules are primarily about dont's and do not provide much content:

• T.120: Use template metaprogramming only when you really need to
• T.121: Use template metaprogramming primarily to emulate concepts
• T.122: Use templates (usually template aliases) to compute types at compile time
• T.123: Use constexpr functions to compute values at compile time
• T.124: Prefer to use standard-library TMP facilities
• T.125: If you need to go beyond the standard-library TMP facilities, use an existing library

Honestly, I don't think template metaprogramming is so horrendous, but the syntax still has a lot of potential.

Let me try to demystify template metaprogramming and write about programming at compile time in general. During this introduction to programming at compile time, I explicitly write about type-traits (T.124: Prefer to use standard-library TMP facilities) and constexpr functions (T.123: Use constexpr functions to compute values at compile time) and implicitly refer to the other rules. Here is my plan:

I introduce template metaprogramming, show how the type-traits library allows you to use template metaprogramming in a well-structured and portable way, and how you can use constexpr functions to replace template metaprogramming magic with ordinary functions.

Template Metaprogramming

How it all started

1994 presented Erwin Unruh at a C++ committee meeting, a program that didn't compile. Here is probably the most famous program that was never compiled.

// Prime number computation by Erwin Unruh
template <int i> struct D { D(void*); operator int(); };

template <int p, int i> struct is_prime {
    enum { prim = (p%i) && is_prime<(i > 2 ? p : 0), i -1> :: prim };
    };

template < int i > struct Prime_print {
    Prime_print<i-1> a;
    enum { prim = is_prime<i, i-1>::prim };
    void f() { D<i> d = prim; }
    };

struct is_prime<0,0> { enum {prim=1}; };
struct is_prime<0,1> { enum {prim=1}; };
struct Prime_print<2> { enum {prim = 1}; void f() { D<2> d = prim; } };
#ifndef LAST
#define LAST 10
#endif
main () {
    Prime_print<LAST> a;
    } 

Erwin Unruh used the Metaware Compilers, but the program is not valid for C++ anymore. A newer variant from the author is here. Okay, why is this program so famous? Let's have a look at the error messages.

I highlighted the important parts in red. I think you see the pattern. The program calculates at compile time the first 30 prime numbers. This means template instantiation can be used to do math at compile time. It is even better. Template metaprogramming is Turing-complete, and can, therefore, be used to solve any computational problem. (Of course, Turing completeness holds only in theory for template metaprogramming because the recursion depth (at least 1024 with C++11) and the length of the names generated during template instantiation provide some limitations.)

How does the magic work?

Let me start traditional.

Calculating at Compile Time

Calculating the factorial of a number is the "Hello World" of template metaprogramming.

// factorial.cpp

#include <iostream>

template <int N>                                                                 // (2)
struct Factorial{
    static int const value = N * Factorial<N-1>::value;
};

template <>                                                                      // (3)
struct Factorial<1>{
    static int const value = 1;
};

int main(){
    
    std::cout << std::endl;
    
    std::cout << "Factorial<5>::value: " << Factorial<5>::value << std::endl;    // (1)
    std::cout << "Factorial<10>::value: " << Factorial<10>::value << std::endl;
    
    std::cout << std::endl;

}

The call factorial<5>::value in line (1) causes the instantiation of the primary or general template in line (2). During this instantiation, Factorial<4>::value will be instantiated. This recursion will end if the fully specialised class template Factorial<1> kicks in in line (3).  Maybe, you like it more pictorial.

Here is the output of the program:

Damn, I almost forgot to prove that the values were calculated at compile time. Here we are with the Compiler Explorer. For simplicity reasons, I only provide a screenshot of the main program and the corresponding assembler instructions.

The first yellow line and the first purple line show it. The factorials of 5 and 10 are just constants and were calculated during compile time. 

The factorial program is friendly but not idiomatic for template metaprogramming.

Manipulating Types at Compile Time

Manipulating types at compile time is typically for template metaprogramming. If you don't believe me, study std::move. Here is what std::move is conceptionally doing:

static_cast<std::remove_reference<decltype(arg)>::type&&>(arg);

Okay. std::move takes an argument arg, deduces the type (decltype(arg)) from it, removes the reference (remove_reverence), and casts it to a rvalue reference (static_cast<...>::type&&>). In essence, this means that std::move returns always a rvalue reference type and, therefore, move semantic can kick it.

How does std::remove_reference from the type-traits library work? Here is a code snippet removing constness from its argument.

template<typename T > 
struct removeConst{ 
    typedef T type;               // (1)
};

template<typename T > 
struct removeConst<const T> { 
    typedef T type;               // (1)
};


int main(){
    
    std::is_same<int, removeConst<int>::type>::value;        // true
    std::is_same<int, removeConst<const int>::type>::value;  // true
  
}

I implemented removeConst the way std::remove_const is probably implemented in the type-traits library. std::is_same from the type-traits library helps me to decide at compile-time if both types are the same. In the case of removeConst<int>, the first or general class template kicks in; in the case of removeConst<const int>, the partial specialization for const T applies. The critical observation is that both class templates return the underlying type in line (1), and the constness is removed.

What's next?

In the next post, I will continue my introduction to programming at compile time. This means, in particular, that I will compare functions and metafunctions before I come to the type-traits library.