Most C++ projects use multiple translation units, and so they need to share
and
across those units. The usage of
is prominent for this purpose, an example being the
whose declarations can be provided by
including the corresponding header
.
Modules are a language feature to share declarations and definitions across translation units. They are an alternative to some use cases of headers.
Modules are orthogonal to
.
// helloworld.cppexportmodulehelloworld;// module declarationimport<iostream>;// import declarationexportvoidhello()// export declaration{std::cout<<"Hello world!\n";}// main.cppimporthelloworld;// import declarationintmain(){hello();}Syntax
export(optional)modulemodule-name module-partition(optional)attr(optional);(1) exportdeclaration(2) export {declaration-seq(optional)}(3) export(optional)importmodule-name attr(optional);(4) export(optional)importmodule-partition attr(optional);(5) export(optional)importheader-name attr(optional);(6) module;(7) module : private;(8) 1) Module declaration. Declares that the current translation unit is a module unit.
2,3) Export declaration. Export all namespace-scope declarations in declaration or declaration-seq.
4,5,6) Import declaration. Import a module unit/module partition/header unit.
7) Starts a
.
8) Starts a
.
Module declarations
A translation unit may have a module declaration, in which case it is considered a module unit. The module declaration, if provided, must be the first declaration of the translation unit (excepted the global module fragment, which is covered later on). Each module unit is associated to a module name (and optionally a partition), provided in the module declaration.
export(optional)modulemodule-name module-partition(optional)attr(optional);The module name consists of one or more identifiers separated by dots (for example: mymodule, mymodule.mysubmodule, mymodule2...). Dots have no intrinsic meaning, however they are used informally to represent hierarchy.
If any identifier in the module name or module partition is defined as an
, the program is ill-formed.
A named module is the collection of module units with the same module name.
Module units whose declaration has the keyword export are termed module interface units; all other module units are termed module implementation units.
For every named module, there must be exactly one module interface unit that specifies no module partition; this module unit is termed the primary module interface unit. Its exported content will be available when importing the corresponding named module.
// (each line represents a separate translation unit)exportmoduleA;// declares the primary module interface unit for named module 'A'moduleA;// declares a module implementation unit for named module 'A'moduleA;// declares another module implementation unit for named module 'A'exportmoduleA.B;// declares the primary module interface unit for named module 'A.B'moduleA.B;// declares a module implementation unit for named module 'A.B'Exporting declarations and definitions
Module interface units can export declarations (including definitions), which can be imported by other translation units. To export a declaration, either prefix it with the export keyword, or else place it inside an export block.
exportdeclarationexport {declaration-seq(optional)}exportmoduleA;// declares the primary module interface unit for named module 'A'// hello() will be visible by translations units importing 'A'exportcharconst*hello(){return"hello";}// world() will NOT be visible.charconst*world(){return"world";}// Both one() and zero() will be visible.export{intone(){return1;}intzero(){return0;}}// Exporting namespaces also works: hi::english() and hi::french() will be visible.exportnamespacehi{charconst*english(){return"Hi!";}charconst*french(){return"Salut!";}}Importing modules and header units
Modules are imported via an import declaration:
export(optional)importmodule-name attr(optional);All declarations and definitions exported in the module interface units of the given named module will be available in the translation unit using the import declaration.
Import declarations can be exported in a module interface unit. That is, if module B export-imports A, then importing B will also make visible all exports from A.
In module units, all import declarations (including export-imports) must be grouped after the module declaration and before all other declarations.
/////// A.cpp (primary module interface unit of 'A')exportmoduleA;exportcharconst*hello(){return"hello";}/////// B.cpp (primary module interface unit of 'B')exportmoduleB;exportimportA;exportcharconst*world(){return"world";}/////// main.cpp (not a module unit)#include<iostream>importB;intmain(){std::cout<<hello()<<' '<<world()<<'\n';}
should not be used in a module unit (outside the global module fragment), because all included declarations and definitions would be considered part of the module. Instead, headers can also be imported as header units with an import declaration:
export(optional)importheader-name attr(optional);A header unit is a separate translation unit synthesized from a header. Importing a header unit will make accessible all its definitions and declarations. Preprocessor macros are also accessible (because import declarations are recognized by the preprocessor).
However, contrary to #include, preprocessing macros already defined at the point of the import declaration will not affect the processing of the header. This may be inconvenient in some cases (some headers use preprocessing macros as a form of configuration), in which case the usage of global module fragment is needed.
/////// A.cpp (primary module interface unit of 'A')exportmoduleA;import<iostream>;exportimport<string_view>;exportvoidprint(std::string_viewmessage){std::cout<<message<<std::endl;}/////// main.cpp (not a module unit)importA;intmain(){std::string_viewmessage="Hello, world!";print(message);}Global module fragment
Module units can be prefixed by a global module fragment, which can be used to include headers when importing the headers is not possible (notably when the header uses preprocessing macros as configuration).
module;preprocessing-directives(optional)
module-declaration
If a module-unit has a global module fragment, then its first declaration must be module;. Then, only
can appear in the global module fragment. Then, a standard module declaration marks the end of the global module fragment and the start of the module content.
/////// A.cpp (primary module interface unit of 'A')module;// Defining _POSIX_C_SOURCE adds functions to standard headers,// according to the POSIX standard.#define _POSIX_C_SOURCE 200809L#include<stdlib.h>exportmoduleA;import<ctime>;// Only for demonstration (bad source of randomness).// Use C++ <random> instead.exportdoubleweak_random(){std::timespects;std::timespec_get(&ts,TIME_UTC);// from <ctime>// Provided in <stdlib.h> according to the POSIX standard.srand48(ts.tv_nsec);// drand48() returns a random number between 0 and 1.returndrand48();}/////// main.cpp (not a module unit)import<iostream>;importA;intmain(){std::cout<<"Random value between 0 and 1: "<<weak_random()<<'\n';}Private module fragment
Primary module interface unit can be suffixed by a private module fragment, which allows a module to be represented as a single translation unit without making all of the contents of the module reachable to importers.
module : private;declaration-seq(optional)
Private module fragment ends the portion of the module interface unit that can affect the behavior of other translation units. If a module unit contains a private module fragment, it will be the only module unit of its module.
exportmodulefoo;exportintf();module:private;// ends the portion of the module interface unit that// can affect the behavior of other translation units// starts a private module fragmentintf()// definition not reachable from importers of foo{return42;}Module partitions
A module can have module partition units. They are module units whose module declarations include a module partition, which starts with a colon : and is placed after the module name.
exportmoduleA:B;// Declares a module interface unit for module 'A', partition ':B'.A module partition represents exactly one module unit (two module units cannot designate the same module partition). They are visible only from inside the named module (translation units outside the named module cannot import a module partition directly).
A module partition can be imported by module units of the same named module.
export(optional)importmodule-partition attr(optional);/////// A-B.cpp exportmoduleA:B;.../////// A-C.cppmoduleA:C;.../////// A.cppexportmoduleA;import:C;exportimport:B;...All definitions and declarations in a module partition are visible by the importing module unit, whether exported or not.
Module partitions can be module interface units (when their module declarations have export). They must be export-imported by the primary module interface unit, and their exported statements will be visible when the module is imported.
export(optional)importmodule-partition attr(optional);/////// A.cpp exportmoduleA;// primary module interface unitexportimport:B;// Hello() is visible when importing 'A'.import:C;// WorldImpl() is now visible only for 'A.cpp'.// export import :C; // ERROR: Cannot export a module implementation unit.// World() is visible by any translation unit importing 'A'.exportcharconst*World(){returnWorldImpl();}/////// A-B.cpp exportmoduleA:B;// partition module interface unit// Hello() is visible by any translation unit importing 'A'.exportcharconst*Hello(){return"Hello";}/////// A-C.cpp moduleA:C;// partition module implementation unit// WorldImpl() is visible by any module unit of 'A' importing ':C'.charconst*WorldImpl(){return"World";}/////// main.cpp importA;import<iostream>;intmain(){std::cout<<Hello()<<' '<<World()<<'\n';// WorldImpl(); // ERROR: WorldImpl() is not visible.}Module ownership
In general, if a declaration appears after the module declaration in a module unit, it is attached to that module.
If a declaration of an entity is attached to a named module, that entity can only be defined in that module. All declarations of such an entity must be attached to the same module.
If a declaration is attached to a named module, and it is not exported, the declared name has
.
exportmodulelib_A;intf(){return0;}// f has module linkageexportintx=f();// x equals 0exportmodulelib_B;intf(){return1;}// OK, f in lib_A and f in lib_B refer to different entitiesexportinty=f();// y equals 1If
are attached to different modules, the program is ill-formed; no diagnostic is required if neither is reachable from the other.
/////// decls.hintf();// #1, attached to the global moduleintg();// #2, attached to the global module/////// Module interface of Mmodule;#include"decls.h"exportmoduleM;exportusing::f;// OK, does not declare an entity, exports #1intg();// Error: matches #2, but attached to Mexportinth();// #3exportintk();// #4/////// Other translation unitimportM;staticinth();// Error: matches #3intk();// Error: matches #4The following declarations are not attached to any named module (and thus the declared entity can be defined outside the module):
definitions with external linkage;
declarations within a
specification.
exportmodulelib_A;namespacens// ns is not attached to lib_A.{exportextern"C++"intf();// f is not attached to lib_A.extern"C++"intg();// g is not attached to lib_A.exportinth();// h is attached to lib_A.}// ns::h must be defined in lib_A, but ns::f and ns::g can be defined elsewhere (e.g.// in a traditional source file).Notes
macro ValueStdFeature
(C++20)Modules — core language support
(C++23)
std and std.compatKeywords
,
,
,
Defect reports
The following behavior-changing defect reports were applied retroactively to previously published C++ standards.
DR Applied to Behavior as published Correct behavior
C++20 it was unclear whether importable headers can
react to preprocessor state from the point of import no reaction
C++20 module names and module partitions could
contain identifiers defined as object-like macros prohibited External links