Browse Prior Art Database

Build Created C++ Template Instantiations

IP.com Disclosure Number: IPCOM000117560D
Original Publication Date: 1996-Mar-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 6 page(s) / 303K

Publishing Venue

IBM

Related People

Bugh, RA: AUTHOR [+2]

Abstract

For various reasons, our C++ templates need to have static data. For our compiler (CSet++* on OS/2 Warp*), this causes duplicate definition problems across shared libraries. A single template instantiation is needed across all the shared libraries in the project. As both the number of shared libraries and the use of templates increased, the problem of finding which shared library should instantiate what template grew to unmanageable proportions. The final solution has been to create tools so that the build determines in which shared library each unique template is instantiated.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 16% of the total text.

Build Created C++ Template Instantiations

      For various reasons, our C++ templates need to have static
data.  For our compiler (CSet++* on OS/2 Warp*), this causes
duplicate definition problems across shared libraries.  A single
template instantiation is needed across all the shared libraries in
the project.  As both the number of shared libraries and the use of
templates increased, the problem of finding which shared library
should instantiate what template grew to unmanageable proportions.
The final solution has been to create tools so that the build
determines in which shared library each unique template is
instantiated.

Following are terms that might be confusing when working on another
operating system:
  import library             On OS/2* Warp, there may be an import
                              library for each shared library.  The
                              import library contains no executable
                              code.  It identifies the external
                              symbols in a dynamic linked library
                              available during runtime.  When
                              developers are creating their dynamic
                              link libraries, they link in the import
                              libraries of other dynamic link
                              libraries.  This says "When you need
                              any of these external symbols, load
                              this library".
  dynamic link library / dll / shared library   For the purposes of
                              this paper, these three terms mean the
                              same thing.  They refer to a library
                              that can be loaded upon demand in OS/2*
                              Warp.

      The compiler can handle duplicate template definitions within
a single translation unit (i.e., within a single shared library or a
single executable).  It can resolve all the duplicate declarations
down to a single definition.

      The duplicate template definition problem really becomes a
problem across shared libraries.  Assume two shared libraries:
zYing.dll and zYang.dll.  Consider the case where code in both
zYing.dll and zYang.dll instantiates a Stack<int> for its private use
(and Stack<class AClass> contains private static data).  When the
linker builds zYing.dll, it is built with a single instantiation of
Stack<int>.  The same is true for zYang.dll, it is built with a
single instantiation...