HP C/aC++ for PA-RISC Software manual Why Use Compile-Time Instantiation, Scope

Why Use Compile-Time Instantiation

Compile-time instantiation is the default. It is easy to use. Your code may compile faster when using compile-time instantiation.

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 135) 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.

Possible Duplicate Symbols in Archive Libraries

If you have built an archive library using automatic instantiation in HP aC++ A.02.00 or A.01.04 and prior versions, and you rebuild that library using the current (compile-time) instantiation, it is possible that duplicate symbol problems not apparent in the prior release will generate errors in the current release.

This is because the current default uses the linker, rather than the assigner, to determine which object file to pick to satisfy instantiation requests.

Invoking Compile-Time Instantiation 135