Where's The Template - Red Hat ENTERPRISE LINUX 3 - USING GCC Using Instructions

Chapter 7. Extensions to the C++ Language
. Backup copies of inline member functions, debugging information, and the internal
interface
tables used to implement virtual functions are all generated in implementation files.
If you use
#pragma implementation
the same basename
implementation
In versions of GNU C++ prior to 2.6.0
whenever you would include it from
implementation
disabled.
If you use an explicit
include the affected header files.
Use the string argument if you want a single implementation file to include code from
multiple header files. (You must also use
implementation
There is no way to split up the contents of a single header file into multiple implementation files.
#pragma implementation
If you define a class in a header file marked with
defined in that class is similar to an explicit
define an independent version of the function. Its definition is used only for inlining with its callers.
Conversely, when you include the same header file in a main source file that declares it as
, the compiler emits code for the function itself; this defines a version of the func-
implementation
tion that can be found via pointers (or by callers compiled without inlining). If all calls to the function
can be inlined, you can avoid emitting the function by compiling with
If any calls were not inlined, you will get linker errors.

7.6. Where's the Template?

C++ templates are the first language feature to require more intelligence from the environment than
one usually finds on a UNIX system. Somehow the compiler and linker have to make sure that each
template instance occurs exactly once in the executable if it is needed, and not at all otherwise. There
are two basic approaches to this problem, which I will refer to as the Borland model and the Cfront
model.
Borland model
Borland C++ solved the template instantiation problem by adding the code equivalent of common
blocks to their linker; the compiler emits template instances in each translation unit that uses
them, and the linker collapses them together. The advantage of this model is that the linker only
has to consider the object files themselves; there is no external complexity to worry about. This
disadvantage is that compilation time is increased because the template code is being compiled
repeatedly. Code written for this model tends to include definitions of all templates in the header
file, since they must be seen to be instantiated.
Cfront model
The AT&T C++ translator, Cfront, solved the template instantiation problem by creating the
notion of a template repository, an automatically maintained place where template instances
are stored. A more modern version of the repository works as follows: As individual object
files are built, the compiler places any template definitions and instantiations encountered in the
1. A file's basename was the name stripped of all leading path information and of trailing suffixes, such as
or or .
.C .cc
1
as your source file. For example, in
by itself is equivalent to
. This was deemed to be more trouble than it was worth, however, and
#pragma implementation
only specifies how to use the file--it doesn't actually include it.)
and
#pragma interface
extern
with no argument, it applies to an include file with
allclass.cc
#pragma implementation "allclass.h"
was treated as an implementation file
allclass.h
even if you never specified
allclass.cc
, it must appear in your source file before you
to include the header file;
#include
also have an effect on function inlining.
#pragma interface
declaration--the compiler emits no code at all to
, giving just
, the effect on a function
-fno-implement-inlines
215
#pragma
.
#pragma
#pragma
#pragma
.
.h