Do templates actually have to be compile-time constructs?

Does the C++ Standard actually mandate that templates must be instantiated at compile-time, not run-time?

If not, is it a convention that we use purely because it obviously makes sense to do it that w开发者_Go百科ay? Or is there some practical reason that would, theoretically, prevent an implementation from existing that can instantiate templates at run-time?

All the standard requires is that the observable behavior be as if the templates were instantiated before the program started to run. Any errors, for example, would have to trigger a message in some phase of the compilation, or at least before runtime. In theory, a compiler could probably defer full instantiation until runtime, but in practice, it would have to have done most of the work at compile time anyway, in order to be sure that any potential error messages appeared.

In a stricter sense, the standard considers "translation" as a unit; an implementation could, and implementations have (and I think some still do) defer instantiation until link time. Which leads to interesting questions when dynamic linking is involved. But the standard is silent about that: dynamic linking is really undefined behavior, as far as the standard is concerned, so it is up to the implementation.

In the end, however: instantiating templates is one of the most expensive operations a compiler does, and requires a very large and complex mechanism. Which no vendor wants to impose on an executable. So regardless of the loopholes, don't expect to see run time instantiation any time soon. Especially as it wouldn't buy you anything anyway: the standard requires that all templates can be instantiated at compile time, so you couldn't instantiate a template somehow dependent on a runtime argument and still be standard conform.

You can't create types in a C++ program at run time (while it is running); they are all known at compile time. Even dynamically loaded shared libraries don't change that; the set of types in the library is known at compile time (when the library is compiled), and the loading program must be able to handle the types that the library exposes.

So, there is no need for template evaluation at run time; the information is all known at compile time.

If you were to instantiate templates at run time, you'd need the compiler and the linker services as part of the run time. That greatly complicates the required run time environment - to no obvious advantage.

Clearly, an interpretive C++ system could, probably would, defer the template instantiation until needed - JIT (just in time) processing. But the compilation is still done before the code is executed.

I'm not in the habit of reading the standard, but Stroustrup's C++ Programming Language is usefully precise.

A.9 Templates: gives the grammar for template declaration; the type-parameter is one of class, typename, or another template - so the type is known, static. (it's not dynamic. one could imagine giving a typeinfo object if C++ were a dynamic language. But that wasn't your question.)

C.13.8.3 Point of Instantiation Binding: says that the point of instantiation for a template is just before the declaration using it.

The example given is concerned with resolving names in the template definition to the correct scope. This would be very hard to do at run-time!

e.g. from Stroustrup C.13.8.3:

template<class T> void f(T a) { g(a); }

void g(int);

void h()
{
    extern g(double);
    f(2);
}

"Here the point of instantiation for f is just before h(), so the g() called in f() is the global g(int) rather than the local g(double)."

I guess this doesn't rule out JIT, but as a practical matter, instantiating the template f requires knowing the correct scoped resolution of g at a particular line. As Jonathan says, you'd need the compiler's services as part of the run-time, along with the full context built up in the compiler while compiling that unit. If that's not a "compile-time" job, I don't know what is.

EDIT: This all relies on an antique version of the C++ standard.