Template Argument Deduction

Most functions you have written so far have a fixed signature. You decide how many parameters they take and of what types, and every call has to match. Some tasks do not fit that pattern. A print routine, for example, should be able to accept one value, three values, or ten, and those values may have different types: an integer, a floating-point number, a string literal, a character. This article shows how C++ variadic templates let one function definition accept such an open-ended list. It also shows how the compiler works out the template arguments it needs from the values you pass in.

Consider a program whose main function makes two calls to a single function named f. The first call passes an integer, a double, and a string. The second call passes a double, a character, a string, and three integers. Both calls use the same function. Before you look at how that function works internally, commit to a prediction about what the first line of output will be.

If your guess matched, you already have the right intuition. If it did not, the trace will show where your mental model differed from what the code does. Watch the execution closely, because the important detail is not only what gets printed but the order in which the function calls happen to produce it.

The same definition therefore accepts very different calls. The source uses two of them as examples: f(1, 2.2, "hello") passes three arguments of three different types, and f(0.2, 'c', "yuck!", 0, 1, 2) passes six arguments mixing floating-point, character, string, and integer values. Both are valid calls to the same template, and neither needs its own overload.

Declaring a pack is only half of the technique. To do something useful with each value, a common approach is to split the arguments into a first value and the rest. The first value is handled directly, and the remaining values are passed to the same function again. Each recursive call therefore has one fewer argument than the call before it. The function calls itself until no arguments remain, and that empty case is the base case that stops the recursion.

The diagram below follows the first call from main. The outermost call is the only one main makes. Every call beneath it exists because the call above it passed along its tail. The deepest call receives nothing and is handled by the base case.

Read the chain from the top. The work for each value happens at a specific level of this chain, and the order in which those levels are reached determines the order of the printed values. The recursion itself does not decide what to do with a value. It only decides which value is next.

The recursive form uses a head parameter followed by a pack named tail. Its signature is template<typename T, typename... Args> void f(T head, Args... tail). When the call f(1, 2.2, "hello") is made, head receives 1, and tail holds 2.2 and "hello". The function then calls f on the tail, and so on. The code below is an illustrative sketch that follows this signature, with the helper and the base case written out so the recursion is complete.

The recursion is not responsible for printing. A second function, which the source names g, takes one argument and writes it to standard output followed by a single space. Because g is also a template, it works for an integer, a double, a character, or a string literal without any change.

The reason g is a separate function is that each function has one clear job. The recursive function walks the argument list. The helper prints a single value. If you later want the values separated by commas instead of spaces, or want them written to a file, only the helper needs to change. The recursion structure stays the same. The source describes the whole arrangement as a simple variant of printf that prints arbitrary lists of values, and notes that the essential ingredients are the head and tail split, the call on the tail, and the empty base case.

The second call in the program passes more arguments, so it shows the pattern more clearly. Its arguments are 0.2, 'c', "yuck!", 0, 1, and 2. The same rule applies at each level: the head is printed, then the function is called on the tail, which is one argument shorter.

The diagram traces the two sources of information for a call to the conversion function template named to. The argument 1.2 feeds the deduction of Source. The default supplies Target. Both feed into the fully resolved specialization.

A function template argument needs to be written explicitly only when it cannot be deduced or when it has no default. Each template parameter in a call therefore comes from one of three places: it is written by the caller, deduced from a function argument, or supplied by a default. Knowing which of the three applies is the key to reading any call.

When a result is unexpected, check each template parameter in turn to see whether it was written, deduced, or defaulted. This keeps you from guessing. Once you know which of the three sources produced the parameter you did not expect, you know which part of the call to change.

For the to family in the source, the Target parameter is the one that comes from the default. A mismatch in Target therefore points to the default, while a mismatch in Source points to the argument that was deduced.