Prior to the introduction of modules, the compilation process for a C++ program went something like this:

• Each .cpp file corresponds to a translation unit. The compiler compiles each .cpp file into an object code file.
• Those object files are then linked together.
• If a .cpp file #includes some other file, the the contents of that file run through the preprocessor, and the result is copied and pasted into the destination .cpp file.

How does this change with the introduction of C++ modules? Are we to understand each source file as being a translation unit in the same way, or has the conceptual understanding of this changed somewhat?

Prior to the introduction of modules, the compilation process for a C++ program went something like this:

• Each .cpp file corresponds to a translation unit. The compiler compiles each .cpp file into an object code file.
• Those object files are then linked together.
• If a .cpp file #includes some other file, the the contents of that file run through the preprocessor, and the result is copied and pasted into the destination .cpp file.

How does this change with the introduction of C++ modules? Are we to understand each source file as being a translation unit in the same way, or has the conceptual understanding of this changed somewhat?

• c++
• c++20
• c++-modules

• 1 I'd argue it doesn't affect the meaning of a translation unit in any way. Modules are a mechanism for sharing declarations (including definitions, which are a type of declaration) across multiple translation units. They provide an alternative to some use cases for header files (in particular, the usage of header files to share declarations across multiple translation units). – Peter Commented Feb 16 at 10:11
• @Peter I think then, taking into account your comment, that all a module does in C++ is perform an include, but rather than performing a simple copy and paste of source code (after running it through the preprocessor) a module instead performs a copy and paste of an abstract syntax tree. Is this description anything like accurate? – user2138149 Commented Feb 16 at 12:03
• 1 I'd say you're over-simplifying. A module provides a means of sharing declarations, but the mechanism (both in code, and how it is supported by an implementation) differs from use of include files. One goal of modules is mitigating pitfalls of relying on the preprocessor (for example, a macro defined before #includeing a header can affect how an #included header is processed [i.e. change the meaning of #included declarations], but will not affect a module). – Peter Commented Feb 16 at 22:21
• 1 I recommend googling: C++ Modules Bill Hoffman - he is author of cmake and he spend lots of time to make modules work with various compilers (work still in progress), he is also a good speaker, so it is hard to find better source. – Marek R Commented Feb 18 at 19:52

1 Answer 1

A module may consist of a single file or a multitude. Each file is a translation unit compiled to binary.

Thinking of a module as a funny header is as misleading as considering a reference a funny pointer. Modules and references both address similar needs to their counterparts but in a different, hopefully better, manner.

The Module Interface Unit creates a Binary Module Interface, which contains the information about the module, including which routines are exported. Besides the interface, the unit contains build system information to ensure the calling system is compatible.

A Module Implementation Unit supplies the exported routines and may use other C++ translation units and libraries.

Note, again, these are all binaries that are linked with the calling code.

A module is independent of the calling code. It is recompiled only when its implementation changes. If the interface doesn't change, the code using it doesn't need to be recompiled; only linking is necessary.

If the Module Interface Unit changes, it is recompiled along with the code using it.