Optimizing your header files.
In the accompanying article, Productivity Tip - Saving time with pre-compiled
headers, we mention that all source files must have their
#include directives in the same order for the compiler to be able to reuse the pre-compiled header information. One of the easiest ways to
maintain the order of your header files is to move the #include directives for each header file into a common header file. Then, you can add
an #include directive for the one common header file in each of your source files. However, this approach creates dependencies between
each source file and any of the header files.
On the other hand, being careless about the order of your #include files can result in the compiler unnecessarily reprocessing some of them.
For projects such as WINDOWS.H that use a large header file for a Library, reprocessing a header file may significantly increase the
compile time. The best solution lies somewhere between the extremes of pre-compiling every header file you'll ever need in the project and
not pre-compiling header files at all. Here, we'll give you our guidelines for organizing your header files to optimize the processing of
pre-compiled headers. In addition, our strategy for organizing your source and header files applies to object-oriented projects under Borland
C++.
CREATE SEPARATE HEADER FILES FOR EACH USER-DEFINED TYPE
You should usually create a separate header file for each user-defined type (class or struct) or for logically related functions. These files
specify the interface and definition of the user-defined type, and they will probably change many times over the course of the project.
In some cases, two or more classes or structs may have a strong relationship or may be highly dependent on
each other. Grouping together
the definitions of these types may be a valuable reminder of their relationship, but unfortunately, it forces a recompile of their corresponding
source files when either type definition changes.
INCLUDE USER-DEFINED TYPE HEADER FILES ONLY WHERE NECESSARY
A change in a header file should force a recompile only of the corresponding implementation file and any files that use functions or types
defined in the header file. Therefore, don't add #include directives for header files that define types within a given project in every source
file. Since the header files for most user-defined types are relatively small, reprocessing them once or twice will not affect your compile time
substantially.
INCLUDE LIBRARY HEADER FILES IN ALL SOURCE FILES
To maximize the visibility of their functions or classes and to optimize the use of pre-compiled headers, put #include directives for Library header files in a common header file. You should use an #include directive for this common header file in all source files in the project as the first #include directive. Since larger Library headers are less likely to change than smaller ones, you should place #include directives at the beginning of each source file in decreasing order of size.