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 を見逃すと、コードベースの無関係な部分で失敗を引き起こす可能性がありました。また、プリプロセッサが翻訳単位間で同じヘッダテキストを繰り返し処理するため、コンパイル時間も大幅に増加しました。

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

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

候補者が見逃しがちなこと

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

候補者はしばしば、C++20 モジュールがモジュールのエクスポートされたインターフェースのバイナリ表現であるコンパイルされたモジュールインターフェースユニット (CMI) を生成することを見逃しがちです。テキストヘッダはプリプロセッサによって処理され、マクロ定義をテキストとして含むのに対し、CMIはエクスポートされた関数、型、およびテンプレートに関するセマンティック情報を保持します。プリプロセッサはインポートされたモジュールの内容を処理せず、インポート宣言のみを見ます。したがって、モジュールの実装内またはそのインターフェースユニット内で定義されたマクロは、インポーターには見えません。これは、文字通り #define 指令を含むテキストをコピーする #include とは根本的に異なります。これは、モジュールがテキストのインクルードモデルからセマンティックインポートモデルに移行することを認識する必要があります。

モジュールからエクスポートされたマクロは、#include 指令からのマクロとはどのように異なる動作をするか？

候補者はしばしば、マクロの export import を通常のマクロの動作と混同します。C++20 は、export import を使用してマクロをエクスポートすることを可能にしますが、これらのマクロはモジュールをインポートするコードにのみ影響を与え、そのインポートスコープを越えて漏洩することはありません。#include の場合、マクロはファイルの終わりまで明示的に未定義にされるまで翻訳単位内に持続しますが、モジュールからエクスポートされたマクロは、モジュールへのインポート翻訳単位の公開範囲にスコープされます。さらに、複数のモジュールが矛盾するマクロをエクスポートする場合、衝突はインポート時に検出され、コンパイル中に後で静かに再定義エラーを引き起こすことはありません。このスコープの動作は、テキストのインクルードが欠いている衛生を提供します。

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

候補者はしばしば、C++20 モジュールが、ヘッダのように、ビルド開始前にモジュールの依存関係を理解する必要があることを見逃しがちです。ヘッダはコンパイル中に依存関係が発見されるのに対して、モジュールはコンパイルユニットです。モジュールはテキストファイルではなくコンパイル単位であるため、ビルドシステムはモジュールインターフェースユニットを解析して、何をエクスポートし、何をインポートするかを決定する必要があります。これには、まずモジュールインターフェースユニットをスキャンして依存関係グラフを構築し、その後に依存順にコンパイルするという二段階のビルドプロセスが必要です。プリプロセッサからの独立性により、ヘッダのインクルードに対する従来の #ifdef ガードは無関係になり、モジュールインターフェースのマクロベースの設定は制限されます。ビルドシステムは、単にソースファイルを追跡するのではなく、コンパイルされたモジュールアーティファクト（BMI - バイナリモジュールインターフェース）を追跡する必要があり、依存関係の追跡とインクリメンタルビルドの作業方法が根本的に変わります。