| Thinking in C++ Vol 2 - Practical Programming |
|
Prev |
Home |
Next |
The separation model of template compilation separates function template definitions or static data member definitions from their
declarations across translation units, just like you do with ordinary functions
and data, by exporting templates. After reading the preceding two
sections, this must sound strange. Why bother to have the inclusion model in
the first place if you can just adhere to the status quo? The reasons are both
historical and technical.
Historically, the inclusion model was the first to experience
widespread commercial use all C++ compilers support the inclusion model. Part
of the reason for that was that the separation model was not well specified
until late in the standardization process, but also that the inclusion model is
easier to implement. A lot of working code was in existence long before the
semantics of the separation model were finalized.
The separation model is so difficult to implement that, as
of Summer 2003, only one compiler front end (EDG) supports the separation
model, and at the moment it still requires that template source code be
available at compile time to perform instantiation on demand. Plans are in
place to use some form of intermediate code instead of requiring that the
original source be at hand, at which point you will be able to ship
pre-compiled templates without shipping source code. Because of the lookup
complexities explained earlier in this chapter (about dependent names being
looked up in the template definition context), a full template definition still
has to be available in some form when you compile a program that instantiates
it.
The syntax to separate the source code of a template
definition from its declaration is easy enough. You use the export keyword:
// C05:OurMin2.h
// Declares min as an exported template
// (Only works with EDG-based compilers)
#ifndef OURMIN2_H
#define OURMIN2_H
export template<typename T> const T&
min(const T&,
const T&);
#endif //
OURMIN2_H ///:~
Similar to inline or virtual, the export
keyword need only be mentioned once in a compilation stream, where an exported
template is introduced. For this reason, we need not repeat it in the
implementation file, but it is considered good practice to do so:
// C05:OurMin2.cpp
// The definition of the exported min template
// (Only works with EDG-based compilers)
#include "OurMin2.h"
export
template<typename T> const T& min(const
T& a, const T& b) {
return (a < b) ? a : b;
} ///:~
The UseMin files used previously only need to include
the correct header file (OurMin2.h), and the main program doesn t
change. Although this appears to give true separation, the file with the
template definition (OurMin2.cpp) must still be shipped to users (because
it must be processed for each instantiation of min( )) until such
time as some form of intermediate code representation of template definitions
is supported. So while the standard does provide for a true separation model,
not all of its benefits can be reaped today. Only one family of compilers
currently supports export (those based on the EDG front end), and these
compilers currently do not exploit the potential ability to distribute template
definitions in compiled form.
| Thinking in C++ Vol 2 - Practical Programming |
|
Prev |
Home |
Next |
