C++20: Module Interface Unit and Module Implementation Unit<\/a>“.<\/p>\nThe idea of a submodule is straightforward. Consequently, I start with them.<\/p>\n
Submodules<\/h2>\n
A module can import modules and then re-export them.<\/p>\n
The module math<\/span>\u00a0imports in the following example the submodules math.math1<\/span> and math.math2<\/span>.<\/p>\n\n- Module math<\/span><\/li>\n<\/ul>\n
<\/p>\n
\n
\/\/ mathModule.ixx<\/span>\n\nexport<\/span> module math;\n\nexport<\/span> import math.math1;\nexport<\/span> import math.math2;\n<\/pre>\n<\/div>\nThe expression export import math.math1<\/span> imports the module math.math<\/span>1 and re-exports it as part of the module\u00a0\u00a0math<\/span>.<\/p>\nFor completeness, here are the math.math1<\/span> and math.math2. <\/span>I used a point to separate the module math<\/span> from its submodules. This point is not necessary.<\/p>\n\n- Submodule math.math1<\/span><\/li>\n<\/ul>\n
<\/p>\n
\n
\/\/ mathModule1.ixx<\/span>\n\nexport<\/span> module math.math1; \/\/ (1) <\/span>\n\nexport<\/span> int<\/span> add<\/span>(int<\/span> fir, int<\/span> sec) { \/\/ (2)<\/span>\n return<\/span> fir +<\/span> sec;\n}\n<\/pre>\n<\/div>\n\n- Submodule math.math2<\/span><\/li>\n<\/ul>\n
<\/p>\n
\n
\/\/ mathModule2.ixx<\/span>\n\nexport<\/span> module math.math2; \/\/ (1) <\/span>\n\nexport<\/span> { \/\/ (2)<\/span>\n int<\/span> mul(int<\/span> fir, int<\/span> sec) {\n return<\/span> fir *<\/span> sec;\n }\n}\n<\/pre>\n<\/div>\nIf you look carefully, you recognize a slight difference in the export statements (2) in the modules math.math1<\/span> and math.math2<\/span>. math.math1<\/span> uses an export specifier and math.math2<\/span> as a so-called export group or export block.<\/p>\nFrom the client’s perspective, using the math<\/span> module is straightforward.<\/p>\n\n- Client program<\/li>\n<\/ul>\n
<\/p>\n
\n
\/\/ mathModuleClient.cpp<\/span>\n\nimport std.core;\nimport math;\n\nint<\/span> main<\/span>() {\n\n std::<\/span>cout <<<\/span> std::<\/span>endl;\n\n std::<\/span>cout <<<\/span> \"add(3, 4): \"<\/span> <<<\/span> add(3<\/span>, 4<\/span>) <<<\/span> std::<\/span>endl;\n std::<\/span>cout <<<\/span> \"mul(3, 4): \"<\/span> <<<\/span> mul(3<\/span>, 4<\/span>) <<<\/span> std::<\/span>endl;\n \n}\n<\/pre>\n<\/div>\nCompiling, linking, and executing the program works as expected with the Microsoft implementation of modules:<\/p>\n
<\/p>\n
\n
cl.exe \/<\/span>std:<\/span>c++<\/span>latest \/<\/span>c \/<\/span>experimental:<\/span>module mathModule1.ixx \/<\/span>EHsc \/<\/span>MD \/\/ (3)<\/span>\ncl.exe \/<\/span>std:<\/span>c++<\/span>latest \/<\/span>c \/<\/span>experimental:<\/span>module mathModule2.ixx \/<\/span>EHsc \/<\/span>MD \/\/ (3)<\/span>\ncl.exe \/<\/span>std:<\/span>c++<\/span>latest \/<\/span>c \/<\/span>experimental:<\/span>module mathModule.ixx \/<\/span>EHsc \/<\/span>MD \/\/ (3)<\/span>\ncl.exe \/<\/span>std:<\/span>c++<\/span>latest \/<\/span>experimental:<\/span>module mathModuleClient.cpp mathModule1.obj mathModule2.obj mathModule.obj \/<\/span>EHsc \/<\/span>MD \/\/ (4)<\/span>\n<\/pre>\n<\/div>\n![\"mathModuleClientFix\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2020\/05\/mathModuleClientFix.png\")
<\/p>\n
Each compilation process (3) produces two artifacts: The IFC file (interface file ) *.ifc,<\/span> which is implicitly used in (4), and the\u00a0 *.obj<\/span> file, which is explicitly used in (4).<\/p>\nI already mentioned that a submodule is just a module. Each submodule has a module declaration (1). Consequently, I can create a second client only interested in math.math1<\/span> module.<\/p>\n\n- \u00a0Second client program<\/li>\n<\/ul>\n
<\/p>\n
\n
\/\/ mathModuleClient1.cpp<\/span>\n\nimport std.core;\nimport math.math1;\n\nint<\/span> main<\/span>() {\n\n std::<\/span>cout <<<\/span> std::<\/span>endl;\n\n std::<\/span>cout <<<\/span> \"add(3, 4): \"<\/span> <<<\/span> add(3<\/span>, 4<\/span>) <<<\/span> std::<\/span>endl;\n \n}\n<\/pre>\n<\/div>\nIt’s sufficient to compile the new client program and link it. The existing module math.math1<\/span> works fine.<\/p>\n<\/p>\n
\n
cl.exe \/<\/span>std:<\/span>c++<\/span>latest \/<\/span>experimental:<\/span>module mathModuleClient1.cpp mathModule1.obj \/<\/span>EHsc \/<\/span>MD\n<\/pre>\n<\/div>\n![\"mathModuleClient1Fix\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2020\/05\/mathModuleClient1Fix.png\")
<\/h2>\n
The division of modules into modules and submodules is a means for the module designer to give the user of the module the possibility to import more granular parts of the module. This observation does not apply to module partitions.<\/p>\n
Module Partitions<\/h2>\n
A module can be divided into partitions. Each partition consists of a module interface unit (partition interface file) and zero or more module implementation units (see “C++20: Module Interface Unit and Module Implementation Unit<\/a>“). The names the partitions export are imported and re-exported by the primary module interface unit (primary interface file). The name of a partition must begin with the name of the module. The partitions can not exist on their own.<\/p>\nThe description of module partitions is more challenging to understand than its implementation. In the following lines, I rewrite the math<\/span> module and its submodules math.math1<\/span> and math.math2<\/span> to module partitions. In this straightforward process, I refer to the shortly introduced terms of module partitions.<\/p>\n\n- \u00a0Primary interface file mathPartition.ixx<\/span><\/li>\n<\/ul>\n
<\/p>\n
\n
\/\/ mathPartition.ixx<\/span>\n\nexport<\/span> module math; \/\/ (1)<\/span>\n\nexport<\/span> import :<\/span>math1; \/\/ (2)<\/span>\nexport<\/span> import :<\/span>math2; \/\/ (2)<\/span>\n<\/pre>\n<\/div>\nThe primary interface file consists of the module declaration (1). It imports and re-exports the partitions math1<\/span> and math2<\/span> using colons (2). The name of the partitions must begin with the name of the module. Consequently, you don’t have to specify them.<\/p>\n\n- Module partitions (mathPartition1.ixx<\/span>, and mathPartition2.ixx<\/span>)<\/li>\n<\/ul>\n
<\/p>\n
\n
\/\/ mathPartition1.ixx<\/span>\n\nexport<\/span> module math:<\/span>math1; \/\/ (1) <\/span>\n\nexport<\/span> int<\/span> add<\/span>(int<\/span> fir, int<\/span> sec) {\n return<\/span> fir +<\/span> sec;\n}\n<\/pre>\n<\/div>\n<\/p>\n
\n
\/\/ mathPartition2.ixx<\/span>\n\nexport<\/span> module math:<\/span>math2; \/\/ (1) <\/span>\n\nexport<\/span> { \n int<\/span> mul(int<\/span> fir, int<\/span> sec) {\n return<\/span> fir *<\/span> sec;\n }\n}\n<\/pre>\n<\/div>\nLike the module declaration, (1) declares a module interface partition. A module interface partition is also a module interface unit. The name math<\/span> stands for the module and math1<\/span> or math2<\/span> for the partition.<\/p>\n\n- Client program<\/li>\n<\/ul>\n
<\/p>\n
\n
\/\/ mathModuleClient.cpp<\/span>\n\nimport std.core;\nimport math;\n\nint<\/span> main<\/span>() {\n\n std::<\/span>cout <<<\/span> std::<\/span>endl;\n\n std::<\/span>cout <<<\/span> \"add(3, 4): \"<\/span> <<<\/span> add(3<\/span>, 4<\/span>) <<<\/span> std::<\/span>endl;\n std::<\/span>cout <<<\/span> \"mul(3, 4): \"<\/span> <<<\/span> mul(3<\/span>, 4<\/span>) <<<\/span> std::<\/span>endl;\n \n}\n<\/pre>\n<\/div>\nYou may have already assumed it: the client program is identical to the one I previously used with submodules. The same observation holds for the creation of the executable.<\/p>\n
<\/p>\n
\n
cl.exe \/<\/span>std:<\/span>c++<\/span>latest \/<\/span>c \/<\/span>experimental:<\/span>module mathPartition1.ixx \/<\/span>EHsc \/<\/span>MD\ncl.exe \/<\/span>std:<\/span>c++<\/span>latest \/<\/span>c
![\"\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2021\/09\/TimelineCpp20Modules.png\")
<\/p>\n