Red Hat ENTERPRISE LINUX 4 Manual page 268

260
complexity, and thus potential for error; for some code this can be just as transparent, but in
practice it can been very difficult to build multiple programs in one directory and one program
in multiple directories. Code written for this model tends to separate definitions of non-inline
member templates into a separate file, which should be compiled separately.
When used with GNU ld version 2.8 or later on an ELF system such as GNU/Linux, G++ supports
the Borland model. On other systems, G++ implements neither automatic model.
A future version of G++ will support a hybrid model whereby the compiler will emit any instantia-
tions for which the template definition is included in the compile, and store template definitions and
instantiation context information into the object file for the rest. The link wrapper will extract that
information as necessary and invoke the compiler to produce the remaining instantiations. The linker
will then combine duplicate instantiations.
In the mean time, you have the following options for dealing with template instantiations:
1. Compile your template-using code with
tension listing all of the template instantiations used in the corresponding object files
.rpo
which could be instantiated there; the link wrapper,
to tell the compiler where to place those instantiations and rebuild any affected object files. The
link-time overhead is negligible after the first pass, as the compiler will continue to place the
instantiations in the same files.
This is your best option for application code written for the Borland model, as it will just work.
Code written for the Cfront model will need to be modified so that the template definitions are
available at one or more points of instantiation; usually this is as simple as adding
tmethods.cc
For library code, if you want the library to provide all of the template instantiations it needs,
just try to link all of its object files together; the link will fail, but cause the instantiations to be
generated as a side effect. Be warned, however, that this may cause conflicts if multiple libraries
try to provide the same instantiations. For greater control, use explicit instantiation as described
in the next option.
2. Compile your code with
template instances, and explicitly instantiate all the ones you use. This approach requires more
knowledge of exactly which instances you need than do the others, but it's less mysterious
and allows greater control. You can scatter the explicit instantiations throughout your program,
perhaps putting them in the translation units where the instances are used or the translation units
that define the templates themselves; you can put all of the explicit instantiations you need into
one big file; or you can create small files like
#include "Foo.h"
#include "Foo.cc"
template class Foo int ;
template ostream& operator
for each of the instances you need, and create a template instantiation library from those.
If you are using Cfront-model code, you can probably get away with not using
-fno-implicit-templates
template definitions.
If you use one big file to do the instantiations, you may want to compile it without
-fno-implicit-templates
instantiations (but not by any other files) without having to specify them as well.
G++ has extended the template instantiation syntax given in the ISO standard to allow forward
declaration of explicit instantiations (with
for a template class (i.e. the vtable) without instantiating any of its members (with
to the end of each template header.
-fno-implicit-templates
(ostream&, const Foo int &);
when compiling files that don't
so you get all of the instances required by your explicit
Chapter 7. Extensions to the C++ Language
. The compiler will generate files with the ex-
-frepo
collect2
to disable the implicit generation of
), instantiation of the compiler support data
extern
, will then update the
the member
#include
files
.rpo
#include
),
inline