取代傳統 include 的 C++20 Modules（1/N）

在 Heresy 來看，C++20 的模組的基本概念是用「import MODULE_NAME;」來取代「#include "LIBRARY.H"」這種前處理器指示詞（preprocessor directives），讓編譯器不需要在前處理階段把整個外部的 header 檔案拉進來。

而用來取代 header 檔案讓編譯器知道有哪些東西可以用的，則是一種新的 binary 形式的「Built Module Interface」（BMI）檔案（gcc 似乎把它叫做「Compiled Module Interface」、參考）；這樣的檔案在 Visual Studio 的副檔名會是 .ifc、g++ 是 .gcm、clang 則是 .pcm。

使用新的模組設計的優點，大概有：

• 模組的設計是讓開發者可以自行決定哪些東西需要匯出讓外界使用的；開發者可以更明確地讓不想被外部使用的東西不會被外部存取到。
• 由於這個 BMI 檔是可以預先建置的 binary 檔案，所以如果在專案中要多次使用同一個模組的時候，就可以共用同一個已經產生的 BMI 檔、不需要每次都個別轉譯。
  所以在大型專案、同樣的模組被多次使用的時候就不會像舊的 header 一樣要處理同樣的內容很多次，也因此是有可能縮短建置所需要的時間的。
• 由於使用模組的時候會先建立出 BMI 檔案、在設計上也會排除外部的巨集造成的影響，所以不會像使用 header 的時候、有可能會因為 include 順序的不同而造成巨集不同、進而讓程式運作不同的問題。
• 技術上，自己開發的函示庫如果是用模組的型式的話，應該是可以只釋出 BMI 和編譯好的 lib 檔案、完全不需要釋出可供人閱讀的程式碼（以前大多會要釋出 .h）。
  不過以目前測試的感覺來看，在編譯器的設計上應該不建議這樣做？

不過也由於引進了新的 BMI 檔案，所以整個程式建置的架構也會有所變化、會需要引入新的 BMI 檔案產生流程、而且檔案建置的相依性也比以前更多，所以很有可能會需要調整整個建置的流程。

再加上要建立模組也需要使用 import、export、module 等新語法，所以既有的程式如果要改用模組的形式、也是需要相當大幅度地修改程式碼的。

不過，由於 C++20 的模組可以和舊的 header 混合使用、並沒有一次全部轉換的必要性，算是有一定的彈性。

另一方面、由於模組對於巨集的處理方法算是有很大的變化，所以如果是巨集使用比較多的舊程式、要改寫成模組的形式可能會有很大的問題。

而為了方便把既有的程式以模組的形式來使用，C++20 也有提供「header unit」的形式，讓開發者可以快速地將既有的 header 檔案轉換成 BMI 的形式來匯入；這基本上算是一種感覺很接近 precompiled header、但是實際上不一樣的過渡方案，雖然在使用上會和真正使用模組不同，但是還是會有一些優點的。
這部分可以參考《Compare header units, modules, and precompiled headers》。

#pragma once
 
inline constexpr int iValue = 10;
 
int getInt();

#include "MyModule.h"
 
int getInt()
{
  return iValue;
}

#include <iostream>
 
#include "MyModule.h"
 
int main()
{
  std::cout << getInt() << "\n";
}

cl /std:c++20 /EHsc /c MyModule.cpp
cl /std:c++20 /EHsc main.cpp MyModule.obj

g++ -std=c++20 -c MyModule.cpp
g++ -std=c++20 main.cpp MyModule.o

clang++ -std=c++20 -c MyModule.cpp
clang++ -std=c++20 main.cpp MyModule.o

如果要把上面的範例，改成用模組的形式來寫要怎麼做呢？首先，要先把 MyModule.h 改成定義模組介面的檔案。檔案副檔名的部分，Visual Studio 是建議用 .ixx、clang 似乎是建議用 .cppm、gcc 似乎沒有特別的建議。

這邊是選擇使用 Visual Studio 建議的 .ixx 來命名；修改完後的 MyModule.ixx 內容如下：

export module MyModule;
 
inline constexpr int iValue = 10;
 
export int getInt();

這邊程式的意義大致如下：

• • 第一行的「export module MyModule;」是一種模組宣告，代表這個檔案是用來定義一個名稱是 MyModule 的模組的介面，並且會匯出讓外部可以使用這個模組。
  • 定義一個全域變數 iValue、並指定他的值。不過這邊沒有加上「export」，所以之後在外部會無法看到它的存在。
  • 最後宣告的 getInt() 這個函式的介面。因為前面有加上「export」，所以外部可以使用他。

由於這個檔案已經不是 header 檔案的性質了，所以也就不需要使用「#pragma once」這類的 include guard 語法（維基百科）了。相對地，這種拿來定義模組介面的檔案會需要經過編譯器處理、不像 header 檔一樣不需要任何處理。

MyModule.cpp 的部分，因為建置過程的時候產生的物件檔可能會和 MyModule.ixx 衝突，所以建議把名字改掉。這邊是改名成 MyModule_impl.cpp， 它的內容如下：

module MyModule;
 
int getInt()
{
  return iValue;
}

這邊只有把本來的「#include "MyModule.h"」改成「module MyModule;」、代表這個檔案是在針對 MyModule 這個模組提供實作的部分；而其他的部分基本上都不用動。

最後，主程式 main.cpp 的部分：

#include <iostream>
 
import MyModule;
 
int main()
{
  std::cout << getInt() << "\n";
}

這邊也只要把「#include "MyModule.h"」改成「import MyModule;」，代表要匯入 MyModule 這個模組來使用就可以了。

和前面使用 Header 的版本一個很大的不同，是使用模組的話，在 main.cpp 這邊是沒有辦法使用沒有匯出的 iValue 這個變數的！如果試著把它加進去的話，是會看到變數未宣告的錯誤的。

Visual Studio 的建置指令（2022 17.12）

cl /std:c++20 /EHsc /c MyModule.ixx
cl /std:c++20 /EHsc /c MyModule_impl.cpp
cl /std:c++20 /EHsc main.cpp MyModule.obj MyModule_impl.obj

g++ 的建置指令（14.2）

g++ -std=c++20 -fmodules-ts -c -x c++ MyModule.ixx
g++ -std=c++20 -fmodules-ts -c MyModule_impl.cpp
g++ -std=c++20 -fmodules-ts main.cpp MyModule.o MyModule_impl.o

clang 的建置指令（18.1）

clang++ -std=c++20 -c -fmodule-output -x c++-module MyModule.ixx
clang++ -std=c++20 -c -fprebuilt-module-path=. MyModule_impl.cpp
clang++ -std=c++20 -fprebuilt-module-path=. main.cpp MyModule_impl.o MyModule.o

這邊的建置流程如果把連結的部分獨立出來後再畫成流程圖的話，會是下面的狀況：

可以看到，因為 .ixx 也需要編譯、然後產生的 BMI 檔案在編譯其他檔案的時候又要用到，所以整個流程和相依性都會變得更複雜。

而如果有多個模組、模組之間又有匯入別的模組的話，其實整個建置的順序會很難判斷。也因此，以往 C++ 同一個專案下要平行建置很簡單，但是一旦引進模組後，要判斷檔案之間的相依姓、決定建置順序就會變得相當地複雜…

所以其實 C++ 標準的 P1689R5（PDF）也定義了一個 JSON 的格式標準來描述檔案之間的相依性；Visual Studio 和 clang 應該是都有對應的方法可以產生這樣的報告。

而 Visual Studio 基本上會自己去管理建置順序，但是如果要自己寫 Makefile 的話，感覺就會有點想哭了？