モチベーション

簡単に答えると、C++モジュールはヘッダそれはまた翻訳ユニット。これは、新しいコンテキストキーワードである とともに使用して、ライブラリの宣言にアクセスすることができるという点で、ヘッダーに似ています。importこれは翻訳単位（複雑なモジュールの場合は複数）であるため、コンパイルされます。別々にそして一度だけ。（#include文字通り内容をコピーする) この組み合わせにより、次のような多くの利点が得られます。

1. 分離: モジュール ユニットは独立した翻訳単位であるため、usingインポートする翻訳単位や他のモジュールのマクロや宣言/ディレクティブに影響を与えず、またそれらから影響を受けることもない独自のマクロや宣言/ディレクティブのセットを持ちます。これにより、あるヘッダーの識別子#defineが別のヘッダーで使用されることによる衝突が防止されます。 の使用はusing慎重に行う必要がありますが、モジュール インターフェイスの名前空間スコープであっても、記述することは本質的に有害ではありませんusing namespace。
2. インターフェース制御: モジュール ユニットは、内部リンク (または を使用static) namespace {}、export(C++98 以降、このような目的のために予約されているキーワード)、またはどちらも使用せずにエンティティを宣言できるため、クライアントが使用できるコンテンツの量を制限できます。これは、namespace detailヘッダー間で競合する可能性があるイディオム (同じ包含名前空間でそれを使用する) を置き換えます。
3. 重複排除: 多くの場合、ヘッダー ファイルで宣言を提供し、別のソース ファイルで定義を提供する必要がなくなるため、冗長性とそれに伴う相違の機会が削減されます。
4. 定義ルール違反の回避: ODRは、定義する特定のエンティティ（型、インライン関数/変数、テンプレート）を、それを使用するすべての翻訳単位で定義します。モジュールはエンティティを1回だけ定義して、それにもかかわらず、意味クライアントに。また、内部リンク宣言によってすでに ODR に違反している既存のヘッダーは、モジュールに変換されると不正な形式ではなくなり、診断は不要になります。
5. 非ローカル変数の初期化順序import: （一意の）変数を含む翻訳単位間の依存関係を確立するため定義、明らかに順序がある静的ストレージ期間を持つ非ローカル変数を初期化するC++17 では、初期化順序を制御できる変数が提供されていましたが、モジュールではこれを通常の変数に拡張しています (変数はまったくinline必要ありません)。inline
6. モジュールプライベート宣言: モジュール内で宣言され、エクスポートも内部リンクも持たないエンティティは、モジュール内の任意の翻訳単位で (名前で) 使用可能であり、既存の または の選択肢の間の便利な中間点を提供しますstatic。実装がこれらをどのように扱うかはまだわかりませんが、これらは動的オブジェクト内の「非表示の」(または「エクスポートされていない」) シンボルの概念に密接に対応しており、この実用的な動的リンク最適化を言語で認識できる可能性があります。
7. ABI安定性: (ODR 互換性の目的がモジュール内で関連しない) のルールは、inline非インライン関数が共有ライブラリのアップグレードの ABI 境界として機能できる実装戦略をサポートするように調整されました (ただし、必須ではありません)。
8. コンパイル速度: モジュールの内容は、それを使用するすべての翻訳単位の一部として再解析する必要がないため、多くの場合、コンパイルははるかに高速に進みます。モジュールは依存関係の順序で個別に処理する必要があるため、コンパイルのクリティカル パス (無限並列ビルドの待ち時間を制御する) は実際には長くなる可能性がありますが、合計 CPU 時間が大幅に短縮され、一部のモジュール/クライアントのみの再構築ははるかに高速になります。
9. ツーリング: および を含む「構造宣言」にはimport、moduleプロジェクトの依存関係グラフを理解する必要のあるツールによって簡単かつ効率的に検出できるように、使用上の制限があります。この制限により、これらの一般的な単語の識別子としての既存の使用のほとんどすべてが許可されます。

アプローチ

モジュールで宣言された名前はクライアントで見つけられる必要があるため、重要な新しい種類の名前検索翻訳単位間で機能するルールが必要です。引数依存の参照とテンプレートのインスタンス化の正しいルールを取得することが、この提案が標準化されるまでに10年以上かかった大きな要因でした。単純なルールは、（明らかな理由により内部リンクと互換性がないことを除けばexport）のみ名前検索。（例えば)decltypeまたはテンプレート パラメーターは、エクスポートされているかどうかに関係なく、まったく同じ動作をします。

モジュールは、クライアントが利用できるように型、インライン関数、テンプレートを提供する必要があるため、コンテンツ使用される場合、通常、コンパイラはモジュールを処理するときにアーティファクトを生成します（これはコンパイルされたモジュールインターフェース）には、クライアントが必要とする詳細な情報が含まれています。CMIは、プリコンパイル済みヘッダーただし、関連するすべての翻訳単位に同じヘッダーが同じ順序で含まれていなければならないという制約はありません。また、モジュールから特定の名前のみをインポートするという機能に類似するものはありませんが、Fortran モジュールの動作に似ています。

コンパイラは に基づいて CMI を見つけることができなければならないimport foo;(また に基づいてソース ファイルを見つけることがimport :partition;できなければならない) ため、“foo” から (CMI) ファイル名へのマッピングを知っている必要があります。Clang では、この概念を「モジュール マップ」という用語で表現しています。一般に、暗黙的なディレクトリ構造や、ソース ファイル名と一致しないモジュール (またはパーティション) 名などの状況をどのように処理するかはまだわかっていません。

非機能

他の「バイナリヘッダー」技術と同様に、モジュールは流通メカニズム(秘密主義の人は、ヘッダーと、含まれているテンプレートのすべての定義を提供することを避けたいと思うかもしれません)。また、コンパイラーがモジュールを使用して各プロジェクトの CMI を再生成することはできますが、従来の意味での「ヘッダーのみ」でもありません。

他の多くの言語では（例えば、Python）、モジュールはコンパイルだけでなく命名単位でもあるが、C++モジュールは名前空間ではないC++ にはすでに名前空間があり、モジュールによって使用法や動作が変わることはありません (一部は下位互換性のためです)。ただし、よく知られた名前空間名を持つライブラリの場合、特に他のモジュールの名前と紛らわしい名前空間名を持つ場合、モジュール名が名前空間名と一致することが予想されます。( はnested::nameモジュール名 としてレンダリングされる場合があります。これは、 が許可されていないnested.nameためです。 は、 C++20 では慣例を除き、意味を持ちません。).::.

モジュールは、pImpl イディオムまたは防止する脆弱な基本クラスの問題クライアントのクラスが完成している場合でも、そのクラスを変更するには、一般にクライアントを再コンパイルする必要があります。

最後に、モジュールは、マクロいくつかのライブラリのインターフェースの重要な部分である。次のようなラッパーヘッダーを提供することが可能である。

// wants_macros.hpp
import wants.macros;
#define INTERFACE_MACRO(x) (wants::f(x),wants::g(x))

export module simple;
import <string_view>;
import <memory>;
using std::unique_ptr;  // not exported
int *parse(std::string_view s) {/*…*/}  // cannot collide with other modules
export namespace simple {
  auto get_ints(const char *text)
  {return unique_ptr<int[]>(parse(text));}
}

import simple;
int main() {
  return simple::get_ints("1 1 2 3 5 8")[0]-1;
}