Syntactically, an explicit instantiation declaration is an explicit
instantiation definition preceded by the extern keyword. This C++11
feature is controlled by the
LANGLVL(EXTENDED) or
LANGLVL(EXTENDED0X) compiler
group suboptions, or by individual suboptions
LANGLVL(EXTERNTEMPLATE) and
LANGLVL(NOEXTERNTEMPLATE).
When multiple
LANGLVL suboptions are applied, the
last one wins. For example, the support for explicit instantiation
declaration is disabled when
LANGLVL(NOEXTERNTEMPLATE) is
set. The default settings for
LANGLVL(EXTERNTEMPLATE) are
as follows:
| compat366 |
strict98 |
extended |
extended0x |
|---|
| N |
N |
Y |
Y |
There are several things to be considered when using explicit instantiation
declarations:
- (IBM extension) An explicit instantiation declaration of a class
template specialization does not cause implicit instantiation of said
specialization.
- If, in a translation unit, a user-defined inline function is subject
to an explicit instantiation declaration and not subject to an explicit
instantiation definition:
- implicit instantiation of said function will still occur regardless
of whether it will be inlined or not.
- (IBM extension) no out-of-line copy of the function will be generated
in that translation unit regardless of whether compiler option KEEPINLINES is
enabled or not.
Note: This does not limit the behavior for functions implicitly
generated by the compiler. Implicitly declared special members such
as the default constructor, copy constructor, destructor and copy
assignment operator are inline and the compiler may instantiate them.
In particular, out-of-line copies may be generated.
- Degradation of the amount of inlining achieved on functions that
are not "inline" and are subject to explicit instantiation declarations
may occur.
- When a non-pure virtual member function is subject to an explicit
instantiation declaration, either directly or through its class, the
virtual member function must be subject to an explicit instantiation
definition somewhere in the entire program or an unresolved symbol
error may result at link time.
- When implicit instantiation of a class template specialization
is allowed, the user program must be written as if a use requiring
the implicit instantiation of all virtual member functions of that
class specialization occurs or an unresolved symbol error for a virtual
member function may result at link time.
- When implicit instantiation of a class template specialization
is allowed and the specialization is subject to explicit instantiation
declaration, the class template specialization must be subject to
an explicit instantiation definition somewhere in the user program
or an unresolved symbol error may result at link time.
The following compiler options interact with explicit instantiation
declarations:
| INLINE |
All functions, subject to explicit instantiation
declaration or not, will be considered for inlining. |
TEMPINC,
TEMPLATEREGISTRY
|
Explicit instantiation declarations are honored.
Referenced specializations that are subject to explicit instantiation
declaration but not subject to explicit instantiation definition in
a translation unit will not be instantiated because of that translation
unit. |
The following IBM language extensions interact with explicit instantiation
declarations:
#pragma instantiate
|
Semantically the same as an explicit instantiation
definition. |
#pragma do_not_instantiate
|
This pragma provides a subset of the functionality
of standard C++ explicit instantiation declarations. It is provided
for backwards compatibility purposes only. New applications should
use standard C++11 explicit instantiation declarations. |
#pragma ishome
#pragma hashome
|
#pragma ishome will cause generation
of the virtual function table (VFT) for a class template specialization
irrespective of explicit instantiation declarations of the specialization. |