Version 1.9 Build 1556

News	FAQ
Search	Home

Next: System generation makefile rules Up: System generation Previous: Object libraries

Subsections

Template instantiation

C++ template instantiation in AIPS++

C++ template classes

AIPS++ makes heavy use of C++ template classes, also referred to as ``parameterized types''. These are typically used to implement ``container'' classes, for example Set, List, and Array classes, which serve to aggregate objects of another type. In C++, Set would be defined in ``template'' form as Set<T>, where the template type (or parameter), T, represents some as yet unspecified data type. This saves having to code Set classes separately for int, float, or general Object data types.

The C++ compiler ``instantiates'' the Set<T> class template for objects of type float (say) when it compiles a piece of code which declares that it wants to use Set<float>.

Global functions can also be templated. The argument list and return value may be defined in terms of template type T, where T often (but not necessarily) refers to a template class.

It often happens that particular template classes and functions can be implemented more efficiently for a particular template type by manual coding rather than by instantiation of the class or function template. C++ allows ``template specializations'' to be written for particular instances of template classes, but some compilers may require these to be registered in a particular way.

Instantiation mechanisms

While no two C++ compilers use exactly the same template instantiation mechanism there are two basic types:

automatic:

Some compilers deduce what templates need to be instantiated, the only outside intervention needed being provided by compile-line options. These compilers maintain a ``template repository'' which holds intermediate files generated in the instantiation process. Older CFRONT-based compilers did all template instantiation at link time, but more modern ``native'' compilers do as much as possible when the object library is generated. They include template object files together with those generated from the class implementation files in order to speed up the linking phase.

Since the compiler needs to locate all C++ class implementation and header files required for the instantiation this is a non-trivial operation and this method is notoriously bug-ridden.

manual:

The GNU C++ compiler, g++, cannot deduce what templates need to be instantiated. However, it does accept a small C++ source file which includes the necessary class implementation and header files and declares the template of the desired type.

The proliferation of template instantiation mechanisms has presented a significant challenge for the AIPS++ system, particularly in avoiding the introduction of compiler-specific procedures.

Template repositories

Compilers which maintain template repositories have mostly been accomodated via the use of PTRDBGD, PTROPTD variables in makedefs, and also in distinguishing between the archiver used for C++ object libraries (CXXAR) and other libraries (AR).

Template specialization and the Sun native compiler

The Sun native compiler requires template specializations to be registered in the template instantiation options file, Template.opt, which resides in the template repository. Within AIPS++ these specializations are registered in specializations files which reside in the same directory as the C++ code. A specialize rule is supplied with the initial version of makedefs supplied for sun4sol_ntv installations, and specialize is added as a dependency of allsys. The specialize rule checks for the existence of a specializations file and if found merges its contents into Template.opt. In this way the compiler specific behaviour is isolated to the local makedefs file and a set of specializations files which are ignored by other compilers.

Do-it-yourself (diy) templates

The GNU C++ compiler, g++, must have template instantiation files supplied to it. This ``do-it-yourself'' mode is enabled by setting the TEMPLATES variable in makedefs (p) to diy.

Templates to be instantiated are discovered during code development via the list of unresolved symbols which results when attempting to compile a program. The linker reports the mangled names of the templates and these may be demangled with the GNU version of c++filt (the name mangling scheme used by g++ differs from other compilers).

It is up to the programmer to supply the name of the class implementation file and any required header files for each template to be instantiated. This information is recorded as an entry in the templates file as described in the entry for mkinst (p). The templates files are maintained within the AIPS++ system and programmers may also create private copies for code development.

templates files may reside in any imp, app or tst directory. However, these are handled in different ways when compiling the system (see chapter 11 for programmer usage):

Template instantiations generated in an implement directory are added to the related system object library so that they may be shared by all applications and test programs which use that library. By convention such templates files are restricted to the _ReposFiller ``module'' for each AIPS++ package.
app directories contain only a single application so the template instantiation files generated therein are not pre-compiled but instead are added to the compilation command for the application.
Since tst directories may contain several test programs the template instantiation files are pre-compiled and inserted into a temporary object library which is deleted after all test programs have been compiled.