Single Compilation Unit

In the C/C++ compilation model (formally "translation environment"), individual .c/.cpp source files are preprocessed into translation units, which are then translated (compiled) separately by the compiler into multiple object (.o or .obj) files. These object files can then be linked together to create a single executable file or library. However, this leads to multiple passes being performed on common header files, and with C++, multiple template instantiations of the same templates in different translation units.

The Single Compilation Unit technique uses pre-processor directives to "glue" different translation units together at compile time rather than at link time. This reduces the overall build time, due to eliminating the duplication, but increases the incremental build time (the time required after making a change to any single source file that is included in the Single Compilation Unit), due to requiring a full rebuild of the entire unit if any single input file changes. Therefore, this technique is appropriate for a set of infrequently modified source files with significant overlap (many or expensive common headers or templates), or source files that frequently require recompilation together, such as due to all including a common header or template that changes frequently.

Another disadvantage of SCU is that it is serial, compiling all included source files in sequence in one process, and thus cannot be parallelized, as can be done in separate compilation (via distcc or similar programs). Thus SCU requires explicit partitioning (manual partitioning or "sharding" into multiple units) to parallelize compilation.

SCU also allows an optimizing compiler to perform interprocedural optimization without requiring link-time optimization, therefore allowing optimizations such as inlining, and helps avoiding implicit code bloat due to exceptions, side effects, and register allocation. These optimizations are often not possible in many compilers, due to independent compilation, where optimization happens separately in each translation unit during compilation, but the "dumb linker" simply links object files, without performing any optimizations itself, and thus interprocedural optimization between translation units is not possible.

For example, if you have the source files foo.cpp and bar.cpp, they can be placed in a Single Compilation Unit as follows:

#include "foo.cpp"
#include "bar.cpp"

Suppose foo.cpp and bar.cpp are:

//foo.cpp
#include <iostream> // A large, standard header
#include "bar.h"    // Declaration of function 'bar'

int main()          // Definition of function 'main'
{ 
  bar();
}

//bar.cpp
#include <iostream> // The same large, standard header

void bar()          // Definition of function 'bar'
{
  ...
}

Now the standard header file (iostream) is compiled only once, and function bar may be inlined into function main, despite being from another module.

• Precompiled headers
• C/C++ preprocessor
• Whole program optimization