HP aC++/HP C Programmer's Guide (B3901-90036; A.06.26; September 2011)

If your development environment uses a version control system that is sensitive to file
modifications, you may want to use the current default, compile-time instantiation, to
avoid major code rebuilds.
NOTE: If you have used automatic instantiation with earlier versions of HP aC++ there
may be some migration issues. See “Migrating from Automatic Instantiation to
Compile-time Instantiation” (page 167) for more information.
Scope
If your source code contains templates and you do not specify any template command-line
options nor explicit instantiations, compile-time instantiation takes place for any use of
a template. If you specify a template command-line option, the option takes precedence
for all translation units on the command line. Any explicit instantiation takes precedence
over either a command-line option or compile-time instantiation.
Usage
Compared with developer-directed instantiation, compile-time instantiation involves less
coding time for the developer. However, the design of your application may require the
use of some form of directed instantiation.
Migrating from Automatic Instantiation to Compile-time Instantiation
If you have used automatic instantiation with earlier versions of HP aC++ there will be
some known migration problems. The following migration problems may occur:
• Creating object files
• Creating an executable
• Closing a set of object files prior to creating a library (.a or .so)
• Creating a shared library (.so)
The following sections describe specific migration scenarios and illustrate possible
migration problems and solutions:
Possible Duplicate Symbols in Shared Libraries
An existing compiler defect may be more apparent, if in HP aC++ A.02.00 or A.01.04
and prior versions you built a shared library using automatic instantiation (the prior
default using the assigner) and now build that library using the current default
(compile-time) instantiation. The defect relates to template objects with constructors or
other runtime initializers that have been globally defined in more than one shared library
on the link line. If such an object is defined in n shared libraries, it will be initialized and
destructed n times at runtime.
When building the same application with the current default, the libraries are not closed
prior to the final link, and the likelihood of a template symbol being defined in more
than one shared library will increase.
Invoking Compile-Time Instantiation 167