Browse Prior Art Database

Efficient Method for Implementing Pre-Compiled Headers for C and C ++

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

Publishing Venue

IBM

Related People

Brolley, DM: AUTHOR [+3]

Abstract

For most applications, the largest proportion of the time required to compile a source file is in the processing of the header files that it includes. This assertion is certainly true for most C + +* applications, where on average more than 70% of the preprocessed source is from the header files. This percentage increases to well over 90% (often closer to 98%!) for typical object-oriented applications, where the bulk of the source of a translation-unit comprises the declarations of class libraries and frameworks that are used by the source file.

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

Efficient Method for Implementing Pre-Compiled Headers for C and C ++

      For most applications, the largest proportion of the time
required to compile a source file is in the processing of the header
files that it includes.  This assertion is certainly true for most C
+ +* applications, where on average more than 70% of the preprocessed
source is from the header files.  This percentage increases to well
over 90% (often closer to 98%!) for typical object-oriented
applications, where the bulk of the source of a translation-unit
comprises the declarations of class libraries and frameworks that are
used by the source file.

      The proposed solution is to save the result of processing the
common header files so that result can be reused by the compiler to
compile the next source file that uses the same set of headers.
Saving the results of the compilation (primarily the symbol-table)
requires some form of persistence, the proposed method for
persistence is based on saving and restoring the memory image of the
program heap.  With this method, daa conversion and pointer
relocations are not necessary.  There are, however, a few
restrictions on the use of dynamically loaded modules.  If, for a
given application, these restrictions are of no consequence, then the
method is potentially much more efficient and easier to retrofit than
the traditional methods for persistence.

      Fig. 1 shows the overall approach in which the state of the
heap is output verbatim to a file thus creating a header store.  This
heap is then restoed by the subsequent activations of the compiler
where it is appropriate to use this header store.

      The C Set ++* compiler runs as a set of at least three or more
communicating processes: the driver xIC, the front-end xICentry and
the back-end xICcode.  Depending on the compiler options, other
processes including ipa, xICinline, and munch will also be created.
The communication between these processes is based on creating
temporary files.  Each of the processes created by the xIC driver is
run to completion before the start of the next process.

      Fig. 2 shows a typical case where four processes have been
created to compile a source file.

      The arrows between the child processes are intermediate files
that are generated by the front-end, and passed to back-end via the
inliner.  Three files are generated:  a header file that contains the
dictionary, a body file that contains the instructions, and a stung
file.

      All source files, i.e., .C files, should include a common
sequence of initial headers.  This way a pre-compiled version of
these headers can be reused in the compilation of all of the
translation-units.

      Also, one pre-compiled header store can be created per
translation-unit.

      This solution uses the convention of having one pre-compiled
header store per project.  This creates a Project.h, file that simply
includes all the system header file...