C++20のモジュールのどの特定の特徴がプリプロセッサマクロの翻訳単位間の漏洩を防ぐのですか？

質問への回答

質問の歴史

C++20以前、**C++**のコンパイルモデルはプリプロセッサディレクティブによるテキストのインクルードに依存していました。ヘッダファイルがインクルードされると、プリプロセッサはそのヘッダのテキストを含むファイルに文字通りコピーしました。このメカニズムにより、ヘッダで定義されたマクロがそれをインクルードしたすべての翻訳単位のグローバル名前空間に漏洩し、微妙なバグや診断が難しい名前の衝突を引き起こしました。

問題

マクロの漏洩は大規模なコードベースでメンテナンスの悪夢を引き起こしました。サードパーティライブラリで定義されたマクロが、消費コード内のキーワードや一般的な識別子を静かに再定義し、コンパイルエラーや実行時エラーを引き起こすことがありました。#undefガードのような従来の作業回避策は手動であり、エラーが発生しやすく、複雑な依存関係グラフ全体にスケールしませんでした。根本的な問題は、プリプロセッサがスコープやインターフェースの境界の概念を持っていなかったことです。

解決策

C++20のモジュールは、プリプロセッサレベルではなく言語レベルで動作するセマンティックインポートメカニズムを導入します。import module_name;でモジュールをインポートすると、コンパイラはインポートする翻訳単位のプリプロセッサディレクティブを実行せずに、モジュールのエクスポートされたインターフェースを処理します。モジュール内で定義されたマクロは、明示的にエクスポートされない限り、そのモジュールの実装にプライベートに保たれます。この特性により、マクロが翻訳単位の境界を越えて漏洩することがなく、真のカプセル化が提供され、名前の汚染が防止されます。

// mathlib.cpp (モジュールの実装)
module;
#define INTERNAL_CALC_FACTOR 3.14  // プライベートマクロ、漏れない

export module mathlib;

export double compute(double x) {
    return x * INTERNAL_CALC_FACTOR;
}

// main.cpp (消費者)
import mathlib;

// INTERNAL_CALC_FACTORはここでは見えない
// #ifdef INTERNAL_CALC_FACTORは偽となる

int main() {
    double result = compute(10.0);  // 正常に動作
}

生活からの状況

ある金融取引会社は、数百万行のコードから成る大規模なコードベースを維持しており、何百ものモジュールにまたがっていました。彼らは、公共ヘッダにMINやMAXのようなマクロを定義しているレガシー数学ライブラリに依存していました。これらのマクロは、標準ライブラリの関数や、minやmaxを変数名または関数テンプレートとして使用するサードパーティのJSON解析ライブラリとしばしば衝突しました。

最初に検討されたアプローチは、すべてのサードパーティヘッダを#pragma onceスタイルのガードでラップし、各インクルード後に手動で問題のあるマクロを#undefすることでした。これには、開発者がどのヘッダがどのマクロを定義しているかを記憶し、各インクルード後にクリーンアップを行う必要がありました。このアプローチは脆弱であり、単一の#undefを見逃すとコードベースの無関係な部分で失敗を引き起こす可能性がありました。また、翻訳単位全体で同じヘッダテキストを繰り返し処理するため、コンパイル時間も大幅に増加しました。

次に検討されたアプローチは、数学ライブラリをマクロの代わりにインライン関数やテンプレートを使用するように変換することでした。この方法は漏洩問題を解決しましたが、レガシーライブラリをかなり改造する必要がありました。数学ライブラリは複数のチームによって使用されており、それを変更することは特定のマクロ評価セマンティクスや副作用に依存する既存の計算が壊れるリスクを伴いました。リファクタリング作業は6か月かかると見積もられ、取引プラットフォームにとってリスクが高すぎると判断されました。

選ばれた解決策はC++20モジュールへの移行でした。チームは、数学ライブラリをモジュールに変換し、数理関数をエクスポートしつつ、マクロをモジュールの実装内に保ちました。#include <mathlib.h>の代わりにimport mathlib;を使用することで、消費翻訳単位はもはやMINやMAXマクロを見ることはありませんでした。このアプローチは、ライブラリの実装に最小限の変更を必要とし—エクスポート文を追加し、ヘッダをモジュールインターフェースユニットに変換するだけで済みました。移行には2週間しかかからず、6か月の時間を短縮しました。その結果、コードベース全体でのマクロ関連の名前の衝突が排除され、モジュールのコンパイルされたインターフェースによりコンパイル時間が15%削減されました。

候補者が見逃すことが多い点

モジュールインターフェースユニットのコンパイル済みバイナリ形式は、テキストヘッダのインクルードと比較してマクロ漏洩をどのように防ぐのですか？

候補者はしばしば、C++20のモジュールがエクスポートされたインターフェースのバイナリ表現であるコンパイル済みモジュールインターフェースユニット（CMI）を生成することを見逃します。テキストヘッダとは異なり、CMIはエクスポートされた関数、型、およびテンプレートに関するセマンティック情報を格納します。

プリプロセッサはインポートされたモジュールの内容を処理せず、インポート宣言のみを見ます。したがって、モジュールの実装内またはそのインターフェースユニットで定義されたマクロは、インポータに対して可視ではありません。これは#includeとは根本的に異なり、#defineディレクティブを含むテキストも文字通りコピーします。

これを理解するには、モジュールがテキストインクルードモデルからセマンティックインポートモデルに移行することを認識する必要があります。バイナリ形式は、明示的にエクスポートされたエンティティのみが可視であり、マクロは特定のエクスポートマクロディレクティブを使用してエクスポートされない限り、エクスポートインターフェースの一部ではありません。

エクスポートインポートを使用してモジュールからエクスポートされたマクロは、#includeディレクティブのマクロとどのように異なる動作をしますか？

候補者はしばしば、モジュールからのマクロのexport importを通常のマクロ動作と混同します。C++20では、マクロをexport importでエクスポートすることを許可していますが、これらのマクロはモジュールをインポートするコードにのみ影響し、そのインポートスコープを超えて漏洩しません。

#includeとは異なり、マクロは明示的に未定義またはファイルの終わりまで翻訳単位内に残りますが、モジュールからエクスポートされたマクロは、インポートする翻訳単位のモジュールへの露出にスコープされます。プリプロセッサはインポートされたマクロをインポート時に定義されたかのように扱いますが、それらは後続のインポートやグローバルプリプロセッサ状態に対して、テキストインクルードの方法とは異なる方法で影響を与えません。

さらに、複数のモジュールが競合するマクロをエクスポートする場合、競合はエクスポート時ではなくインポート時に検出され、コンパイルの後で静かな再定義エラーを引き起こすことはありません。このスコープの動作は、テキストのインクルードが欠いている衛生状態を提供し、マクロが適切な名前空間スコープエンティティのように振舞うことを保証します。

モジュールのプリプロセッサからの独立性は、ビルドシステムの統合および依存関係スキャンにどのように影響しますか？

候補者はしばしば、C++20モジュールが、ヘッダーよりもコンパイル前にモジュール依存関係をビルドシステムが理解する必要があることを見逃します。モジュールはテキストファイルではなく、コンパイルユニットだからです。ビルドシステムはモジュールインターフェースユニットを解析して、何をエクスポートし、何をインポートするかを決定する必要があります。

これには2段階のビルドプロセスが必要です: 最初にモジュールインターフェースユニットをスキャンして依存関係グラフを構築し、その後依存関係順にコンパイルします。プリプロセッサの独立性により、ヘッダのインクルードのための従来の#ifdefガードは無関係であり、モジュールインターフェースのマクロベースの構成は制限されます。ビルドシステムは、単にソースファイルではなく、コンパイルされたモジュールアーティファクト（BMI - バイナリモジュールインターフェース）を追跡する必要があります。

これにより、依存関係の追跡やインクリメンタルビルドの方法が根本的に変わります。ビルドシステムは、独自の依存関係チェーンを持つ中間アーティファクトとしてBMIファイルを管理しなければならず、モジュールを認識したコンパイルグラフをサポートするためにCMakeやBazelなどのビルドツールの更新が必要になります。