Precompiled header

<h2 id="rationale">Rationale</h2>
In the <a href="/facts/C_(programming_language)/Ky2No763">C</a> and <a href="/facts/C%252B%252B/Et0F2qn9">C++</a> <a href="/facts/Programming_language/cWTYbgWa">programming languages</a>, a <a href="/facts/Header_file/fg3KEG4V">header file</a> is a file whose text may be automatically included in another <a href="/facts/Source_code/o9J6Jv23">source file</a> by the <a href="/facts/C_preprocessor/KuhuxKYP">C preprocessor</a> by the use of a <a href="/facts/Preprocessor_directive/RsozxGG0">preprocessor directive</a> in the source file.
Header files can sometimes contain very large amounts of source code (for instance, the header files windows.h and Cocoa/Cocoa.h on <a href="/facts/Microsoft_Windows/bwhAhuSL">Microsoft Windows</a> and <a href="/facts/OS_X/Y93vVpTm">OS X</a>, respectively). This is especially true with the advent of large "header" libraries that make extensive use of <a href="/facts/Template_(C%252B%252B)/TXEqGy7R">templates</a>, like the <a href="/facts/List_of_numerical_libraries/p5kgpwob">Eigen math library</a> and <a href="/facts/Boost_C%252B%252B_libraries/vGLGG51A">Boost C++ libraries</a>. They are written almost entirely as header files that the user #includes, rather than being linked at runtime. Thus, each time the user compiles their program, the user is essentially recompiling numerous header libraries as well. (These would be precompiled into shared objects or <a href="/facts/Dynamic-link_library/vySyC1dz">dynamic link libraries</a> in non "header" libraries.)
To reduce compilation times, some compilers allow header files to be compiled into a form that is faster for the compiler to process. This intermediate form is known as a precompiled header, and is commonly held in a file named with the extension .pch or similar, such as .gch under the <a href="/facts/GNU_Compiler_Collection/t07jh01k">GNU Compiler Collection</a>.

<h2 id="usage">Usage</h2>
For example, given a C++ file source.cpp that includes header.hpp:

//header.hpp
...

//source.cpp
#include "header.hpp"
...

When compiling source.cpp for the first time with the precompiled header feature turned on, the compiler will generate a precompiled header, header.pch. The next time, if the timestamp of this header did not change, the compiler can skip the compilation phase relating to header.hpp and instead use header.pch directly.

<h2 id="common-implementations">Common implementations</h2>
<h3>Microsoft Visual C and C++</h3>
Microsoft <a href="/facts/Visual_C_Plus_Plus/RM3sbYw5">Visual C++</a> (version 6.0 and newer) can precompile any code, not just headers.<a class="footnote-ref" id="fnref:1" href="#fn:1">1</a>
It can do this in two ways: either precompiling all code up to a file whose name matches the /Ycfilename option or (when /Yc is specified without any filename) precompiling all code up to the first occurrence of #pragma hdrstop in the code<a class="footnote-ref" id="fnref:2" href="#fn:2">2</a><a class="footnote-ref" id="fnref:3" href="#fn:3">3</a>
The precompiled output is saved in a file named after the filename given to the /Yc option, with a .pch extension, or in a file named according to the name supplied by the /Fpfilename option.<a class="footnote-ref" id="fnref:4" href="#fn:4">4</a>
The /Yu option, subordinate to the /Yc option if used together, causes the compiler to make use of already precompiled code from such a file.<a class="footnote-ref" id="fnref:5" href="#fn:5">5</a>
pch.h (named stdafx.h before Visual Studio 2017<a class="footnote-ref" id="fnref:6" href="#fn:6">6</a>) is a file generated by the <a href="/facts/Microsoft_Visual_Studio/omNe6Lej">Microsoft Visual Studio</a> <a href="/facts/Integrated_development_environment/jbEINSQf">IDE</a> <a href="/facts/Wizard_(software)/8c4Y3BQ0">wizard</a>, that describes both standard system and project specific <a href="/facts/Header_file/fg3KEG4V">include files</a> that are used frequently but hardly ever change.
The afx in stdafx.h stands for application framework extensions. AFX was the original abbreviation for the <a href="/facts/Microsoft_Foundation_Classes/J2N5pas5">Microsoft Foundation Classes</a> (MFC). While the name stdafx.h was used by default in MSVC projects prior to version 2017, any alternative name may be manually specified.
Compatible compilers will precompile this file to reduce overall compile times. Visual C++ will not compile anything before the #include "pch.h" in the source file, unless the compile option /Yu'pch.h' is unchecked (by default); it assumes all code in the source up to and including that line is already compiled.

<h3>GCC</h3>
Precompiled headers are supported in <a href="/facts/GNU_Compiler_Collection/t07jh01k">GCC</a> (3.4 and newer). GCC's approach is similar to these of VC and compatible compilers. GCC saves precompiled versions of header files using a ".gch" suffix. When compiling a source file, the compiler checks whether this file is present in the same directory and uses it if possible.
GCC can only use the precompiled version if the same compiler switches are set as when the header was compiled and it may use at most one. Further, only preprocessor instructions may be placed before the precompiled header (because it must be directly or indirectly included through another normal header, before any compilable code).
GCC automatically identifies most header files by their extension. However, if this fails (e.g. because of non-standard header extensions), the -x switch can be used to ensure that GCC treats the file as a header.

<h3>clang</h3>
The <a href="/facts/Clang/MH7cjC67">clang</a> compiler added support for PCH in Clang 2.5 / LLVM 2.5 of 2009.<a class="footnote-ref" id="fnref:7" href="#fn:7">7</a> The compiler both tokenizes the input source code and performs syntactic and semantic analyses of headers, writing out the compiler's internal generated <a href="/facts/Abstract_syntax_tree/73AUK1jI">abstract syntax tree</a> (AST) and <a href="/facts/Symbol_table/ILc0WE9u">symbol table</a> to a precompiled header file.<a class="footnote-ref" id="fnref:8" href="#fn:8">8</a>
clang's precompiled header scheme, with some improvements such as the ability for one precompiled header to reference another, internally used, precompiled header, also forms the basis for its modules mechanism.<a class="footnote-ref" id="fnref:9" href="#fn:9">9</a>
It uses the same bitcode file format that is employed by <a href="/facts/LLVM/nPmcspQN">LLVM</a>, encapsulated in clang-specific sections within <a href="/facts/Common_Object_File_Format/ye0Gwm2a">Common Object File Format</a> or <a href="/facts/Extensible_Linking_Format/ro2CYqso">Extensible Linking Format</a> files.<a class="footnote-ref" id="fnref:10" href="#fn:10">10</a>

<h3>C++Builder</h3>
In the default project configuration, the <a href="/facts/C%252B%252BBuilder/293I0the">C++Builder</a> compiler implicitly generates precompiled headers for all headers included by a source module until the line #pragma hdrstop is found.<a class="footnote-ref" id="fnref:11" href="#fn:11">11</a>: 76  Precompiled headers are shared for all modules of the project if possible. For example, when working with the <a href="/facts/Visual_Component_Library/YxGluXeP">Visual Component Library</a>, it is common to include the vcl.h header first which contains most of the commonly used VCL header files. Thus, the precompiled header can be shared across all project modules, which dramatically reduces the build times.
In addition, C++Builder can be instrumented to use a specific header file as precompiled header, similar to the mechanism provided by Visual C++.
C++Builder 2009 introduces a "Precompiled Header Wizard" which parses all source modules of the project for included header files, classifies them (i.e. excludes header files if they are part of the project or do not have an <a href="/facts/Include_guard/5yTrhomK">Include guard</a>) and generates and tests a precompiled header for the specified files automatically.

<h2 id="pretokenized-headers">Pretokenized headers</h2>
A pretokenized header (PTH) is a header file stored in a form that has been run through <a href="/facts/Lexical_analysis/T1JYWpIf">lexical analysis</a>, but no semantic operations have been done on it. PTH is present in Clang before it supported PCH, and has also been tried in a branch of GCC.<a class="footnote-ref" id="fnref:12" href="#fn:12">12</a>
Compared to a full PCH mechanism, PTH has the advantages of language (and dialect) independence, as lexical analysis is similar for the C-family languages, and architecture independence, as the same stream of tokens can be used when compiling for different target architectures.<a class="footnote-ref" id="fnref:13" href="#fn:13">13</a> It however has the disadvantage of not going any further than simple lexical analysis, requiring that <a href="/facts/Syntax_analysis/nRKB01S3">syntactic</a> and <a href="/facts/Semantic_analysis_(compilers)/uVGz8wBw">semantic analysis</a> of the token stream be performed with every compilation. In addition, the time to compile scaling linearly with the size, in lexical tokens, of the pretokenized file, which is not necessarily the case for a fully-fledged precompilation mechanism (PCH in clang allows random access).<a class="footnote-ref" id="fnref:14" href="#fn:14">14</a>
Clang's pretokenization mechanism includes several minor mechanisms for assisting the pre-processor: caching of file existence and datestamp information, and recording <a href="/facts/Inclusion_guard/5yTrhomK">inclusion guards</a> so that guarded code can be quickly skipped over.<a class="footnote-ref" id="fnref:15" href="#fn:15">15</a>

<h2 id="modules">Modules</h2>
Since <a href="/facts/C%252B%252B20/hwpB1Vzp">C++20</a>, C++ has offered <a href="/facts/Modular_programming/sNoqKvRD">modules</a> as a modern alternative to precompiled headers,<a class="footnote-ref" id="fnref:16" href="#fn:16">16</a> however they differ from precompiled headers in that they do not require the preprocessor directive #include, but rather are accessed using the word import. A module must be declared using the word module to indicate that a file is a module. A module, once compiled, is stored as a .pcm (precompiled module) file which acts very similar to a .pch (precompiled header) file.
Modules provide the benefits of precompiled headers in that they compile much faster than traditional headers which are #included and are processed much faster during the linking phase,<a class="footnote-ref" id="fnref:17" href="#fn:17">17</a> but also greatly reduce boilerplate code, allowing code to be implemented in a single file, rather than being separated across an <a href="/facts/Header_file/fg3KEG4V">header file</a> and <a href="/facts/Source_code/o9J6Jv23">source implementation</a> file which was typical prior to the introduction of modules (however, this separation of "interface file" and "implementation file" is still possible with modules, but less common due to the increased boilerplate). Furthermore, modules eliminate the necessity to use <a href="/facts/Include_guard/5yTrhomK">#include guards</a> or <a href="/facts/Pragma_once/LNCNmtAQ">#pragma once</a>, as modules do not directly modify the source code, unlike #includes, which during the preprocessing step must include source code from the specified header. Thus, importing a module is not handled by the <a href="/facts/C_preprocessor/KuhuxKYP">preprocessor</a>, but is rather handled during the compilation phase. Modules, unlike headers, do not have to be processed multiple times during compilation.<a class="footnote-ref" id="fnref:18" href="#fn:18">18</a> However, similar to headers, any change in a module necessitates the recompilation of not only the module itself but also all its dependencies — and the dependencies of those dependencies, et cetera. This being said, much like what was the case with headers, C++ modules do not permit <a href="/facts/Circular_dependency/l6mh3qVC">circular dependencies</a>, and a circular/cyclic dependency will fail to compile.
C++ modules most commonly have the extension .cppm, though some alternative extensions include .ixx and .mxx.<a class="footnote-ref" id="fnref:19" href="#fn:19">19</a> All symbols within a module that the programmer wishes to be accessible outside of the module must be marked export.
Modules do not allow for granular imports of specific namespaces, classes, or symbols within a module, unlike <a href="/facts/Java_(programming_language)/9ScgFyAL">Java</a> or <a href="/facts/Rust_(programming_language)/8JNMV19F">Rust</a> which do allow for the aforementioned.<a class="footnote-ref" id="fnref:20" href="#fn:20">20</a> Importing a module imports all symbols marked with export, making it akin to a wildcard import in Java or Rust. Importing links the file and makes all exported symbols accessible to the importing translation unit, and thus if a module is never imported, it will never be linked.
Since <a href="/facts/C%252B%252B23/8sBupF9c">C++23</a>, the <a href="/facts/C%252B%252B_standard_library/A5vQNSAD">C++ standard library</a> has been exported as a module as well, though as of currently it must be imported in its entirety (using import std;). However, this may change in the future, with proposals to separate the standard library into more modules such as std.core, std.math, and std.io.<a class="footnote-ref" id="fnref:21" href="#fn:21">21</a><a class="footnote-ref" id="fnref:22" href="#fn:22">22</a> The module names std and std.* are reserved by the C++ standard,<a class="footnote-ref" id="fnref:23" href="#fn:23">23</a> however most compilers allow a flag to override this.<a class="footnote-ref" id="fnref:24" href="#fn:24">24</a>
Modules may not export or leak macros, and because of this the order of modules does not matter (however convention is typically to begin with standard library imports, then all project imports, then external dependency imports in alphabetical order).<a class="footnote-ref" id="fnref:25" href="#fn:25">25</a> If a module must re-export an imported module, it can do so using export import, meaning that the module is first imported and then exported out of the importing module, transitively importing modules which the imported module imports itself.<a class="footnote-ref" id="fnref:26" href="#fn:26">26</a> Also, because using statements will not be included into importing files (unless explicitly marked export), it is much less likely that using a using statement to bring symbols into the global namespace will cause name clashes within module translation units. C++ modules do not enforce any notion of namespaces, but it is not uncommon to see projects manually associate modules to namespaces.
Though standard <a href="/facts/C_(programming_language)/Ky2No763">C</a> has not included modules into the standard, dialects of C allow for modules, for example <a href="/facts/Clang/MH7cjC67">Clang</a> supports modules for the C language,<a class="footnote-ref" id="fnref:27" href="#fn:27">27</a> though the syntax and semantics of Clang C modules differ from C++ modules significantly.

<h3>Module partitions and hierarchy</h3>
Modules may have partitions, which separate the implementation of the module across several files. Module partitions are declared using the syntax A:B, meaning the module A has the partition B. Module partitions cannot individually be imported outside of the module that owns the partition itself, meaning that anyone who desires to access code that is part of a module partition must import the entire module that owns the partition.<a class="footnote-ref" id="fnref:28" href="#fn:28">28</a>
To link the module partition B back to the owning module A, write import :B; inside the file containing the declaration of module A or any other module partition of A (say A:C). These import statements may themselves be exported by the owning module, even if the partition itself cannot be imported directly – thus, to import code belonging to partition B that is re-exported by A, one simply has to write import A;.
Other than partitions, C++ modules do not have a hierarchical system, but typically use a hierarchical naming convention, like Java's <a href="/facts/Java_package/C8PmS7K4">packages</a><a class="footnote-ref" id="fnref:29" href="#fn:29">29</a>. In other words, C++ does not have "submodules", meaning the . symbol which may be included in a module name bears no syntactic meaning and is used only to suggest the association of a module.<a class="footnote-ref" id="fnref:30" href="#fn:30">30</a> Meanwhile, only alphanumeric characters plus the period can be used in module names, and so the character * cannot be used in a module name (which otherwise would have been used to denote a wildcard import, like in Java). In C++, the name of a module is not tied to the name of its file or the module's location, unlike Java in which the name of a file must match the name of the public class it declares if any, and the package it belongs to must match the path it is located in. For example, the modules A and A.B in theory are disjoint modules and need not necessarily have any relation, however such a naming scheme is often employed to suggest that the module A.B is somehow related or otherwise associated with the module A.
The naming scheme of a C++ module is inherently hierarchical, and the C++ standard recommends re-exporting "sub-modules" belonging to the same public API (i.e. module alpha.beta.gamma should be re-exported by alpha.beta, etc.), even though dots in module names do not enforce any hierarchy. The C++ standard recommends lower-case ASCII module names (without hyphens or underscores), even though there is technically no restriction in such names. Also, because modules cannot be re-aliased or renamed (short of re-exporting all symbols in another module), the C++ standards recommends organisations/projects to prefix module names with organisation/project names for both clarity and to prevent naming clashes (i.e. google.abseil instead of abseil). Also, unlike Java, whose packages may typically include a TLD to avoid namespace clashes, C++ modules do not have this convention. Thus, it may be more common to see example.myfunctionality.MyModule than com.example.myfunctionality.MyModule, though both names are valid. Similar to Java, some organisations of code will split modules into exporting one class/struct/namespace each, and name the final word in PascalCase to match the name of the exported class, while modules re-exporting multiple "sub-modules" may be in all-lowercase.

<h3>Example</h3>
A simple example of using C++ modules is as follows:
MyClass.cppm

export module myproject.MyClass;

import std;

using String = std::string;

export namespace myproject {
    class MyClass {
    private:
        int x;
        String name;
    public:
        MyClass(int x, const String& name):
            x{x}, name{name} {}

int getX() const noexcept {
            return x;
        }

void setX(int newX) noexcept {
            x = newX;
        };

String getName() const noexcept {
            return name;
        }

void setName(const String& newName) noexcept {
            name = newName;
        }
    };
}

Main.cpp

import std;

import myproject.MyClass;

using myproject::MyClass;

int main() {
    MyClass me(10, "MyName");
    me.setX(15);

std::println("Hello, {}!", me);
}

<h3>Module purview and global module fragment</h3>
Everything above the line export module myproject.MyClass; in the file MyClass.cppm is referred to as what is "outside the module purview", meaning what is outside of the scope of the module. Typically, if headers must be included, all #includes are placed outside the module purview between a line containing only the statement module; and the declaration of export module, like so:

module; // Optional, marks the beginning of the global module fragment (mandatory if an include directive is invoked above the export module declaration)

#include <print>

#include "MyHeader.h"

export module myproject.MyModule; // Mandatory, marks the beginning of the module preamble

module: private; // Optional, marks the beginning of the private module fragment

The file containing main() may declare a module, but typically it does not (as it is unusual to export main() as it is typically only used as an entry point to the program, and thus the file is usually a .cpp file and not a .cppm file). A program is ill-informed if it exports main().
All code which does not belong to any module belongs to the so-called "unnamed module" (also known as the global module fragment), and thus cannot be imported by any module.

<h3>Private module fragment</h3>
A module may declare a "private module fragment" by writing module: private;, in which all declarations or definitions after the line are visible only from within the file, and thus inaccessible from importers of the module. Any module unit that contains a private module fragment must be the only module unit of its module.

<h3>Header units</h3>
Headers may also be imported using import, even if they are not declared as modules – these are called "header units", and they are designed to allow existing codebases to migrate from headers to modules more gradually.<a class="footnote-ref" id="fnref:31" href="#fn:31">31</a> The syntax is similar to including a header, with the difference being that #include is replaced with import and a semicolon is placed at the end of the statement. Header units automatically export all symbols, and differ from proper modules in that they allow the emittance of macros, meaning all who import the header unit will obtain its contained macros. This offers minimal breakage between migration to modules. The semantics of searching for the file depending on whether quotation marks or angle brackets are used apply here as well. For instance, one may write import <string>; to import the <string> header, or import "MyHeader.h"; to import the file "MyHeader.h" as a header unit. Most build systems, such as <a href="/facts/CMake/ICCBEBKF">CMake</a>, do not support this feature yet.

<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Prefix_header/0KEzxrR2">Prefix header</a></li>
<li><a href="/facts/Single_compilation_unit/pFrqlmMN">Single compilation unit</a></li>
<li><a href="/facts/Java_package/C8PmS7K4">Java package</a></li>
<li><a href="/facts/Java_Platform_Module_System/LAGvEqkx">Java Platform Module System</a></li></ul>
<h2 id="notes">Notes</h2>

<h2 id="external-links">External links</h2>
<ul><li><a href="http://gamesfromwithin.com/the-care-and-feeding-of-pre-compiled-headers">The Care and Feeding of Pre-Compiled Headers</a></li>
<li><a href="https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html">Precompiled Headers with GCC</a></li>
<li><a href="http://www.cygnus-software.com/papers/precompiledheaders.html">Fractal eXtreme: Precompiled headers</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">"Creating Precompiled Header Files". MSDN. Microsoft. 2015. Archived from the original on 2018-03-28. Retrieved 2018-03-28. <a href="https://web.archive.org/web/20180328165615/https://msdn.microsoft.com/en-gb/library/szfdksca.aspx" target="_blank">https://web.archive.org/web/20180328165615/https://msdn.microsoft.com/en-gb/library/szfdksca.aspx</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">"Two Choices for Precompiling Code". MSDN. Microsoft. 2015. Retrieved 2018-03-28. <a href="https://msdn.microsoft.com/en-gb/library/2yzw0wyd.aspx" target="_blank">https://msdn.microsoft.com/en-gb/library/2yzw0wyd.aspx</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">"/Yc (Create Precompiled Header File)". MSDN. Microsoft. 2015. Retrieved 2018-03-28. <a href="https://msdn.microsoft.com/en-gb/library/7zc28563.aspx" target="_blank">https://msdn.microsoft.com/en-gb/library/7zc28563.aspx</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">"/Yc (Create Precompiled Header File)". MSDN. Microsoft. 2015. Retrieved 2018-03-28. <a href="https://msdn.microsoft.com/en-gb/library/7zc28563.aspx" target="_blank">https://msdn.microsoft.com/en-gb/library/7zc28563.aspx</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">"/Yc (Create Precompiled Header File)". MSDN. Microsoft. 2015. Retrieved 2018-03-28. <a href="https://msdn.microsoft.com/en-gb/library/7zc28563.aspx" target="_blank">https://msdn.microsoft.com/en-gb/library/7zc28563.aspx</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">"Can I use #include "pch.h" instead of #include "stdafx.h" as my precompile header in Visual Studio C++?". Stack Overflow. <a href="https://stackoverflow.com/questions/51928685/can-i-use-include-pch-h-instead-of-include-stdafx-h-as-my-precompile-heade" target="_blank">https://stackoverflow.com/questions/51928685/can-i-use-include-pch-h-instead-of-include-stdafx-h-as-my-precompile-heade</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">"LLVM 2.5 Release Notes". releases.llvm.org. <a href="https://releases.llvm.org/2.5/docs/ReleaseNotes.html" target="_blank">https://releases.llvm.org/2.5/docs/ReleaseNotes.html</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
<li id="fn:8">The Clang Team (2018). "Precompiled Header and Modules Internals". Clang 7 documentation. Retrieved 2018-03-28. <a href="http://clang.llvm.org/docs/PCHInternals.html" target="_blank">http://clang.llvm.org/docs/PCHInternals.html</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></li>
<li id="fn:9">The Clang Team (2018). "Precompiled Header and Modules Internals". Clang 7 documentation. Retrieved 2018-03-28. <a href="http://clang.llvm.org/docs/PCHInternals.html" target="_blank">http://clang.llvm.org/docs/PCHInternals.html</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></li>
<li id="fn:10">The Clang Team (2018). "Precompiled Header and Modules Internals". Clang 7 documentation. Retrieved 2018-03-28. <a href="http://clang.llvm.org/docs/PCHInternals.html" target="_blank">http://clang.llvm.org/docs/PCHInternals.html</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></li>
<li id="fn:11">Swart, Bob (2003). Borland C++ Builder 6 Developer's Guide. Sams Publishing. ISBN 9780672324802. <a href="9780672324802" target="_blank">9780672324802</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></li>
<li id="fn:12">"pph - GCC Wiki". gcc.gnu.org. <a href="https://gcc.gnu.org/wiki/pph" target="_blank">https://gcc.gnu.org/wiki/pph</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></li>
<li id="fn:13">The Clang Team (2018). "Pretokenized Headers (PTH)". Clang 7 documentation. Archived from the original on 2018-03-22. Retrieved 2018-03-28. <a href="https://web.archive.org/web/20180322163257/https://clang.llvm.org/docs/PTHInternals.html" target="_blank">https://web.archive.org/web/20180322163257/https://clang.llvm.org/docs/PTHInternals.html</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></li>
<li id="fn:14">The Clang Team (2018). "Pretokenized Headers (PTH)". Clang 7 documentation. Archived from the original on 2018-03-22. Retrieved 2018-03-28. <a href="https://web.archive.org/web/20180322163257/https://clang.llvm.org/docs/PTHInternals.html" target="_blank">https://web.archive.org/web/20180322163257/https://clang.llvm.org/docs/PTHInternals.html</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></li>
<li id="fn:15">The Clang Team (2018). "Pretokenized Headers (PTH)". Clang 7 documentation. Archived from the original on 2018-03-22. Retrieved 2018-03-28. <a href="https://web.archive.org/web/20180322163257/https://clang.llvm.org/docs/PTHInternals.html" target="_blank">https://web.archive.org/web/20180322163257/https://clang.llvm.org/docs/PTHInternals.html</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></li>
<li id="fn:16">cppreference.com (2025). "Modules (since C++20)". Retrieved 2025-02-20. <a href="https://en.cppreference.com/w/cpp/language/modules" target="_blank">https://en.cppreference.com/w/cpp/language/modules</a> <a href="#fnref:16" class="footnote-back-ref">↩</a></li>
<li id="fn:17">"Compare header units, modules, and precompiled headers". Microsoft. 12 February 2022. <a href="https://learn.microsoft.com/en-us/cpp/build/compare-inclusion-methods?view=msvc-170" target="_blank">https://learn.microsoft.com/en-us/cpp/build/compare-inclusion-methods?view=msvc-170</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></li>
<li id="fn:18">"Compare header units, modules, and precompiled headers". Microsoft. 12 February 2022. <a href="https://learn.microsoft.com/en-us/cpp/build/compare-inclusion-methods?view=msvc-170" target="_blank">https://learn.microsoft.com/en-us/cpp/build/compare-inclusion-methods?view=msvc-170</a> <a href="#fnref:18" class="footnote-back-ref">↩</a></li>
<li id="fn:19">"Overview of modules in C++". Microsoft. 24 April 2023. <a href="https://learn.microsoft.com/en-us/cpp/cpp/modules-cpp?view=msvc-170" target="_blank">https://learn.microsoft.com/en-us/cpp/cpp/modules-cpp?view=msvc-170</a> <a href="#fnref:19" class="footnote-back-ref">↩</a></li>
<li id="fn:20">Importing (import in Java and use in Rust) in Java and Rust differs from C++. In the former, an import simply aliases the type or de-qualifies a namespace (similar to using in C++) as a convenience feature, because Java loads .class files dynamically as necessary and Rust automatically links all modules/crates, thus making all types available simply by fully quantifying all namespaces. However, in C++ modules are not automatically all linked, and thus they must be manually "imported" to be made accessible, as strictly speaking import links the file at compilation. This is further due to the fact that C++ does not define namespaces directly by modules. Thus, it is probably more appropriate to compare import in C++ to import on Python, which tells the interpreter to load the contents of a module into their own namespace. <a href="/wiki/Java_class_file" target="_blank">/wiki/Java_class_file</a> <a href="#fnref:20" class="footnote-back-ref">↩</a></li>
<li id="fn:21">C++ Standards Committee. (2018). P0581R1 - Modules for C++. Retrieved from https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0581r1.pdf <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0581r1.pdf" target="_blank">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0581r1.pdf</a> <a href="#fnref:21" class="footnote-back-ref">↩</a></li>
<li id="fn:22">C++ Standards Committee. (2021). P2412R0 - Further refinements to the C++ Modules Design. Retrieved from https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2412r0.pdf <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2412r0.pdf" target="_blank">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2412r0.pdf</a> <a href="#fnref:22" class="footnote-back-ref">↩</a></li>
<li id="fn:23">cppreference.com (2025). "C++ Standard Library". Retrieved 2025-02-20. <a href="https://en.cppreference.com/w/cpp/standard_library" target="_blank">https://en.cppreference.com/w/cpp/standard_library</a> <a href="#fnref:23" class="footnote-back-ref">↩</a></li>
<li id="fn:24">"Standard C++ modules". <a href="https://clang.llvm.org/docs/StandardCPlusPlusModules.html" target="_blank">https://clang.llvm.org/docs/StandardCPlusPlusModules.html</a> <a href="#fnref:24" class="footnote-back-ref">↩</a></li>
<li id="fn:25">"Compare header units, modules, and precompiled headers". Microsoft. 12 February 2022. <a href="https://learn.microsoft.com/en-us/cpp/build/compare-inclusion-methods?view=msvc-170" target="_blank">https://learn.microsoft.com/en-us/cpp/build/compare-inclusion-methods?view=msvc-170</a> <a href="#fnref:25" class="footnote-back-ref">↩</a></li>
<li id="fn:26">cppreference.com (2025). "Modules (since C++20)". Retrieved 2025-02-20. <a href="https://en.cppreference.com/w/cpp/language/modules" target="_blank">https://en.cppreference.com/w/cpp/language/modules</a> <a href="#fnref:26" class="footnote-back-ref">↩</a></li>
<li id="fn:27">"Modules". clang.llvm.org. <a href="https://clang.llvm.org/docs/Modules.html" target="_blank">https://clang.llvm.org/docs/Modules.html</a> <a href="#fnref:27" class="footnote-back-ref">↩</a></li>
<li id="fn:28">cppreference.com (2025). "Modules (since C++20)". Retrieved 2025-02-20. <a href="https://en.cppreference.com/w/cpp/language/modules" target="_blank">https://en.cppreference.com/w/cpp/language/modules</a> <a href="#fnref:28" class="footnote-back-ref">↩</a></li>
<li id="fn:29">It is more appropriate to compare packages in Java and modules in C++, rather than modules in Java and modules in C++. Modules in C++ and Java differ in meaning. In Java, a module (which is handled by the Java Platform Module System) is used to group several packages together, while in C++ a module is a translation unit, strictly speaking. <a href="/wiki/Java_package#Modules" target="_blank">/wiki/Java_package#Modules</a> <a href="#fnref:29" class="footnote-back-ref">↩</a></li>
<li id="fn:30">cppreference.com (2025). "Modules (since C++20)". Retrieved 2025-02-20. <a href="https://en.cppreference.com/w/cpp/language/modules" target="_blank">https://en.cppreference.com/w/cpp/language/modules</a> <a href="#fnref:30" class="footnote-back-ref">↩</a></li>
<li id="fn:31">"Walkthrough: Build and import header units in Microsoft Visual C++". Microsoft. 12 April 2022. <a href="https://learn.microsoft.com/en-us/cpp/build/walkthrough-header-units?view=msvc-170" target="_blank">https://learn.microsoft.com/en-us/cpp/build/walkthrough-header-units?view=msvc-170</a> <a href="#fnref:31" class="footnote-back-ref">↩</a></li>
</ol>

Precompiled header open-in-new

Precompiled header