10.6 Afternotes

Ru-Brd

This chapter deals with two related but different issues: the C++ template compilation models and various C++ template instantiation mechanisms .

The compilation model determines the meaning of a template at various stages of the translation of a program. In particular, it determines what the various constructs in a template mean when it is instantiated . Name lookup is an essential ingredient of the compilation model of course. When we talk about the inclusion model and the separation model, we talk about compilation models. These models are part of the language definition.

The instantiation mechanisms are the external mechanisms that allow C++ implementations to create instantiations correctly. These mechanisms may be constrained by requirements of the linker and other software building tools.

However, the original (Cfront) implementation of templates transcended these two concepts. It created new translation units for the instantiation of templates using a particular convention for the organization of source files. The resulting translation unit was then compiled using what is essentially the inclusion model (although the C++ name lookup rules were substantially different back then). So although Cfront did not implement "separate compilation" of templates, it managed to create an illusion of separate compilation by creating implicit inclusions. Various later implementations provided a somewhat similar implicit inclusion mechanism by default (Sun Microsystems) or as an option (HP, EDG) to provide some amount of compatibility with existing code developed for Cfront.

An example illustrates the details of the Cfront implementation scheme:

  //   File   template.hpp   :  template<class T>  // Cfront doesn't know  typename  void f(T);  //   File   template.cpp   :  template<class T>  // Cfront doesn't know  typename  void f(T)  {  }  //   File   app.hpp   :  class App {   };  //   File   main.cpp   :  #include "app.hpp"  #include "template.hpp"  int main()  {      App a;      f(a);  } 

At link time, Cfront's iterated instantiation scheme then creates a new translation unit including files it expects to contain the implementation of the templates it found in header files. Cfront's convention for this is to replace the .h (or similar) suffix of header files by .c (or one of a few other suffixes like .C or .cpp ). In this case, the generated translation unit becomes

  //   File   main.cpp   :  #include "template.hpp"  #include "template.cpp"  #include "app.hpp"  static void _dummy_(App a1)  {      f(a1);  } 

This translation unit is then compiled with a special option to disable the code generation of any entity defined in an included file. This prevents the inclusion of template.cpp (which was presumably already compiled to another object file) from generating duplicate definitions of any linkable entities it may contain.

The function _dummy_ is used to create references to the specializations that must be instantiated. Note also the reordering of the header files: Cfront actually includes header analysis code that causes unused headers to be omitted from the generated translation unit. Unfortunately, the technique is relatively brittle in the presence of macros with scopes that cross header boundaries.

In contrast, the standard C++ separation model involves the separate translation of two (or more) translation units, followed by an instantiation that has access to the entities of both translation units (primarily enabled by ADL across translation units). Because it is not based on inclusion, it does not impose a particular header file convention, nor do macro definitions in one translation unit pollute the other translation units. However, as we illustrated earlier in this chapter, macros aren't the only way to create surprises in C++, and the export model is exposed to other forms of "pollution."

Ru-Brd