Strings as Template Parameters in C++: A Compile-Time Guide

To understand why we need our StringLiteral class, we first need to look at Non-Type Template Parameters (NTTPs). These aren't new, they've been a fundamental part of C++ since C++98.

You've already used them, probably without thinking much about it. The most common example is std::array.

#include <array>

// T is a TYPE parameter (e.g., int)
// N is a NON-TYPE parameter (e.g., 5)
template<typename T, size_t N>
class std::array;  

// We provide a type 'int' and a value '10'
std::array<int, 10> my_array;
                

A string literal, like "hello", has internal linkage. This means it's essentially private to its source file (.cpp file). The compiler is free to store it however it wants, and it might even merge identical string literals from different files into a single location. Because a string literal doesn't have a stable, unique address across the entire program (i.e., external linkage), a pointer to it was forbidden as a template argument.

Due to this limitation we couldn't just write MyTemplate<"hello">. The rules of the language forbade it. We were stuck—until C++20 expanded the rules for what kind of types could be used as NTTPs, opening the door for our StringLiteral solution.

Here's the struct that puts these ideas into practice. It's a wrapper that holds the string's characters in a way that satisfies the compiler's rules.

#include <cstddef>         // for size_t
#include <string_view>     // for std::string_view

template <size_t N>
struct StringLiteral {
    char value[N]{};

    // The compile-time constructor
    constexpr StringLiteral(const char(&str)[N]) noexcept {
        for (size_t i = 0; i < N; ++i) {
            value[i] = str[i];
        }
    }

    // Handy functions to access the data
    constexpr std::string_view View() const noexcept { return { value, N - 1 }; }
    constexpr size_t Size() const noexcept { return N - 1; }
    // ... other helpers like operator[] ...
};
                

With our StringLiteral struct ready, we can finally do what seemed impossible before. We can pass a string directly as a template argument.

Let's define a function that takes a StringLiteral as a template parameter:

#include <iostream>

template <StringLiteral S>
void logMessage() {
    std::cout << "[LOG]: " << S.View() << std::endl;
}
                

Now, for the magic moment (you'll need a C++20 compiler):

int main() {
    logMessage<"Application Started">();
    logMessage<"Processing Data...">();
}
                

All of this is resolved during compilation, giving us zero-overhead, type-safe, compile-time strings.

While using StringLiteral as a template argument is clean, defining it as a local variable used to be a bit clunky. You had to explicitly provide the size:

// Before C++17, you had to do this:
StringLiteral<6> myStr{"hello"};                    // Verbose!
                

Thankfully, Class Template Argument Deduction (CTAD), introduced in C++17, simplifies this. CTAD allows the compiler to deduce a class's template arguments from its constructor arguments, just like it does for functions.

Because our constructor StringLiteral(const char(&str)[N]) makes the value of N perfectly clear from the input, we can now write:

// With C++17 CTAD, it's this simple:
StringLiteral myStr{"hello"};                          // The compiler deduces N = 6 automatically!
                

This makes our StringLiteral class feel like a natural, built-in part of the language.

This solution perfectly illustrates how modern C++ continues to deliver powerful features that solve long-standing challenges and dramatically improve the quality of life for developers, especially in the world of template metaprogramming.

If you'd like to see the full implementation, this StringLiteral is part of my QkTraits library. Feel free to explore the complete code on GitHub!

StringLiteral in QkTraits on GitHub

I'll be covering some of these advanced scenarios in upcoming deep dives.

Stick around if you're curious about where this goes!