導讀：C++20 標準早已封版，各大編譯器也都已支持了 C++20 中的多數(shù)特性，但迄今為止（2021.7），尚未有哪一款編譯器完整支持 C++20 中的所有特性。本文僅介紹 C++20 四大特性當中的 Module 部分。

文｜馬建亭

網(wǎng)易云信資深 C++ 開發(fā)工程師

C++20 最大的特性是什么？

最大的特性是迄今為止沒有哪一款編譯器完全實現(xiàn)了所有特性。

有人認為 C++20 是 C++11 以來最大的一次改動，甚至比 C++11 還要大。本文僅介紹 C++20 四大特性當中的 Module 部分，分為三部分：

• 探究 C++ 編譯鏈接模型的由來以及利弊

• 介紹 C++20 Module 機制的使用姿勢

• 總結(jié) Module 背后的機制、利弊、以及各大編譯器的支持情況

扒一扒頭文件的由來

C++ 是兼容 C 的，不但兼容了 C 的語法，也兼容了 C 的編譯鏈接模型。1973年初，C 語言基本定型：有了預(yù)處理、支持結(jié)構(gòu)體；編譯模型也基本定型為：預(yù)處理、編譯、匯編、鏈接四個步驟并沿用至今；1973年，K&R 二人使用 C 語言重寫了 Unix 內(nèi)核。

為何要有預(yù)處理？為何要有頭文件？在 C 誕生的年代，用來跑 C 編譯器的計算機 PDP-11 的硬件配置是這樣的：內(nèi)存：64 KiB 硬盤：512 KiB。編譯器無法把較大的源碼文件放入狹小的內(nèi)存，故當時 C 編譯器的設(shè)計目標是能夠支持模塊化編譯，即將源碼分成多個源碼文件、挨個編譯，以生成多個目標文件，最后整合（鏈接）成一個可執(zhí)行文件。

C 編譯器分別編譯多個源碼文件的過程，實際上是一個 One pass compile 的過程，即：從頭到尾掃描一遍源碼、邊掃描邊生成目標文件、過眼即忘（以源碼文件為單位）、后面的代碼不會影響編譯器前面的決策，該特性導致了 C 語言的以下特征：

• 結(jié)構(gòu)體必須先定義再使用，否則無法知道成員的類型以及偏移，就無法生成目標代碼。

• 局部變量先定義再使用，否則無法知道變量的類型以及在棧中的位置，且為了方便編譯器管理棧空間，局部變量必須定義在語句塊的開始處。

• 外部變量只需要知道類型、名字（二者合起來便是聲明）即可使用（生成目標代碼），外部變量的實際地址由連接器填寫。

• 外部函數(shù)只需知道函數(shù)名、返回值、參數(shù)類型列表（函數(shù)聲明）即可生成調(diào)用函數(shù)的目標代碼，函數(shù)的實際地址由連接器填寫。

頭文件和預(yù)處理恰好滿足了上述要求，頭文件只需用少量的代碼，聲明好函數(shù)原型、結(jié)構(gòu)體等信息，編譯時將頭文件展開到實現(xiàn)文件中，編譯器即可完美執(zhí)行 One pass comlile 過程了。

至此，我們看到的都是頭文件的必要性和益處，當然，頭文件也有很多負面影響：

• 低效：頭文件的本職工作是提供前置聲明，而提供前置聲明的方式采用了文本拷貝，文本拷貝過程不帶有語法分析，會一股腦將需要的、不需要的聲明全部拷貝到源文件中。

• 傳遞性：最底層的頭文件中宏、變量等實體的可見性，可以通過中間頭文件“透傳”給最上層的頭文件，這種透傳會帶來很多麻煩。

• 降低編譯速度：加入 a.h 被三個模塊包含，則 a 會被展開三次、編譯三次。

• 順序相關(guān)：程序的行為受頭文件的包含順影響，也受是否包含某一個頭文件影響，在 C++ 中尤為嚴重（重載）。

• 不確定性：同一個頭文件在不同的源文件中可能表現(xiàn)出不同的行為，導致這些不同的原因，可能源自源文件（比如該源文件包含的其他頭文件、該源文件中定義的宏等），也可能源自編譯選項。

C++20 中加入了 Module，我們先看 Module 的基本使用姿勢，最后再總結(jié) Module 比 頭文件的優(yōu)勢。

Module 的使用

Module（即模塊）避免了傳統(tǒng)頭文件機制的諸多缺點，一個 Module 是一個獨立的翻譯單元，包含一個到多個 module interface file（即模塊接口文件），包含 0 個到多個 module implementation file（即模塊實現(xiàn)文件），使用 Import 關(guān)鍵字即可導入一個模塊、使用這個模塊暴露的方法。

?實現(xiàn)一個最簡單的 Module?

module_hello.cppm：定義一個完整的hello模塊，并導出一個 say_hello_to 方法給外部使用。當前各編譯器并未規(guī)定模塊接口文件的后綴，本文統(tǒng)一使用 ".cppm" 后綴名。".cppm" 文件有一個專用名稱"模塊接口文件"，值得注意的是，該文件不光可以聲明實體，也可定義實體。

main 函數(shù)中可以直接使用 ?hello 模塊：

編譯腳本如下，需要先編譯 module_hello.cppm 生成一個 pcm 文件（Module 緩存文件），該文件包含了 hello 模塊導出的符號。

以上代碼有以下細節(jié)需要注意：

• module hello：聲明了一個模塊，前面加一個 export，則意味著當前文件是一個模塊接口文件（module interface file），只有在模塊接口文件中可以導出實體（變量、函數(shù)、類、namespace等）。一個模塊至少有一個模塊接口文件、模塊接口文件可以只放實體聲明，也可以放實體定義。

• import hello：不需加尖括號，且不同于 include，import 后跟的不是文件名，而是模塊名（文件名為 module_hello.cpp），編譯器并未強制模塊名必須與文件名一致。

• 想要導出一個函數(shù)，在函數(shù)定義/聲明前加一個?export 關(guān)鍵字即可。

• Import 的模塊不具有傳遞性。hello 模塊包含了 string_view，但是 main 函數(shù)在使用 hello 模塊前，依然需要再 import <string_view>; 。

• 模塊中的 Import 聲明需要放在模塊聲明之后、模塊內(nèi)部其他實體聲明之前，即：import <iostream>; 必須放在 export module hello; 之后，void internal_helper() 之前。

• 編譯時需要先編譯基礎(chǔ)的模塊，再編譯上層模塊，buildfile.sh 中先將 module_hello 編譯生成 pcm，再編譯 main。

?接口與實現(xiàn)分離?

上個示例中，接口的聲明與實現(xiàn)都在同一個文件中（.cppm中，準確地說，該文件中只有函數(shù)的實現(xiàn)，聲明是由編譯器自動生成、放到緩存文件pcm中），當模塊的規(guī)模變大、接口變多之后，將所有的實體定義都放在模塊接口文件中會非常不利于代碼的維護，C++20 的模塊機制還支持接口與實現(xiàn)分離。下面我們將接口的聲明與實現(xiàn)分別放到 .cppm 和 .cpp 文件中。

module_hello.cppm：我們假設(shè) say_hello_to、func_a、func_b 等接口十分復雜，.cppm 文件中只包含接口的聲明（square 方法是個例外，它是函數(shù)模板，只能定義在 .cppm 中，不能分離式編譯）。

module_hello.cpp：給出 hello 模塊的各個接口聲明對應(yīng)的實現(xiàn)。

代碼有幾個細節(jié)需要注意：

• 整個 hello 模塊分成了?module_hello.cppm 和 module_hello.cpp?兩個文件，前者是模塊接口文件(module 聲明前有 export 關(guān)鍵字)，后者是模塊實現(xiàn)文件（module implementation file）。當前各大編譯器并未規(guī)定模塊接口文件的后綴必須是 cppm。

• 模塊實現(xiàn)文件中不能 export 任何實體。

• 函數(shù)模板，比如代碼中的 square 函數(shù)，定義必須放在模塊接口文件中，使用 auto 返回值的函數(shù)，定義也必須放在模塊接口文件。

?可見性控制?

在模塊最開始的例子中，我們就提到了模塊的 Import 不具有傳遞性：main 函數(shù)使用 hello 模塊的時候必須 import <string_view>，如果想讓 hello 模塊中的 string_view 模塊暴露給使用者，需使用 export import 顯式聲明：

hello 模塊顯式導出 string_view 后，main 文件中便無需再包含 string_view 了。

?子模塊（Submodule）?

當模塊變得再大一些，僅僅是將模塊的接口與實現(xiàn)拆分到兩個文件也有點力不從心，模塊實現(xiàn)文件會變得非常大，不便于代碼的維護。C++20 的模塊機制支持子模塊。

這次 module_hello.cppm 文件不再定義、聲明任何函數(shù)，而是僅僅顯式導出 hello.sub_a、hello.sub_b 兩個子模塊，外部需要的方法都由上述兩個子模塊定義，module_hello.cppm 充當一個“匯總”的角色。

子模塊 module hello.sub_a 采用了接口與實現(xiàn)分離的定義方式：“.cppm” 中給出定義，“.cpp” 中給出實現(xiàn)。

module hello.sub_b 同上，不再贅述。

這樣，hello 模塊的接口和實現(xiàn)文件被拆分到了兩個子模塊中，每個子模塊又有自己的接口文件、實現(xiàn)文件。

值得注意的是，C++20 的子模塊是一種“模擬機制”，模塊 hello.sub_b 是一個完整的模塊，中間的點并不代表語法上的從屬關(guān)系，不同于函數(shù)名、變量名等標識符的命名規(guī)則，模塊的命名規(guī)則中允許點存在于模塊名字當中，點只是從邏輯語義上幫助程序員理解模塊間的邏輯關(guān)系。

?Module Partition?

除了子模塊之外，處理復雜模塊的機制還有 Module Partition。Module Partition 一直沒想到一個貼切的中文翻譯，或者可以翻譯為模塊分區(qū)，下文直接使用 Module Partition。Module Partition 分為兩種：

• module implementation partition

• module interface partition

module implementation partition?可以通俗的理解為：將模塊的實現(xiàn)文件拆分成多個。module_hello.cppm 文件：給出模塊的聲明、導出函數(shù)的聲明。

模塊的一部分實現(xiàn)代碼拆分到 module_hello_partition_internal.cpp 文件，該文件實現(xiàn)了一個內(nèi)部方法 internal_helper。

模塊的另一部分實現(xiàn)拆分到 module_hello.cpp 文件，該文件實現(xiàn)了 func_a、func_b，同時引用了內(nèi)部方法 internal_helper（func_a、func_b 當然也可以拆分到兩個 cpp 文件中）。

值得注意的是， 模塊內(nèi)部 Import 一個 module partition 時，不能 import hello:internal;而是直接import :internal; 。

module interface partition?可以理解為模塊聲明拆分到多個文件中。module implementation partition 的例子中，函數(shù)聲明只集中在一個文件中，module interface partition 可以將這些聲明拆分到多個接口文件。

首先定義一個內(nèi)部 helper：internal_helper：

hello 模塊的 a 部分采用聲明+定義合一的方式，定義在 module_hello_partition_a.cppm 中：

hello 模塊的 b 部分采用聲明+定義分離的方式，module_hello_partition_b.cppm 只做聲明：

module_hello_partition_b.cpp 給出 hello 模塊的 b 部分對應(yīng)的實現(xiàn)：

module_hello.cppm 再次充當了”匯總“的角色，將模塊的 a 部分+ b 部分導出給外部使用：

module implementation partition 的使用方式較為直觀，相當于我們平時編程中“一個頭文件聲明多個 cpp 實現(xiàn)”這種情況。module interface partition 有點類似于 submodule 機制，但語法上有較多差異：

• module_hello_partition_b.cpp 第一行不能使用 import hello:partition_b;雖然這樣看上去更符合直覺，但是不允許。

• 每個 module partition interface 最終必須被 primary module interface file 導出，不能遺漏。

• primary module interface file 不能導出 module implementation file，只能導出 module interface file，故在 module_hello.cppm 中 export :internal; 是錯誤的。

同樣作為處理大模塊的機制，Module Partition 與子模塊最本質(zhì)的區(qū)別在于：子模塊可以獨立的被外部使用者 Import，而 Module Partition 只在模塊內(nèi)部可見。

?全局模塊片段?

（Global module fragments）

C++20 之前有大量的不支持模塊的代碼、頭文件，這些代碼實際被隱式的當作全局模塊片段處理，模塊代碼與這些片段交互方式如下：

事實上，由于標準庫的大多數(shù)頭文件尚未模塊化（VS 模塊化了部分頭文件），整個第二章的代碼在當前編譯器環(huán)境下(Clang12)是不能直接編譯通過的——當前尚不能直接 import < iostream >? 等模塊，通全局模塊段則可以進行方便的過渡（在全局模塊片段直接 #include <iostream>），另一個過渡方案便是下一節(jié)所介紹的 Module Map——該機制可以使我們能夠?qū)⑴f的? iostream編譯成一個 Module。

?Module Map?

Module Map 機制可以將普通的頭文件映射成 Module，進而可以使舊的代碼吃到 Module 機制的紅利。下面便以 Clang13 中的 Module Map 機制為例：

假設(shè)有一個 a.h 頭文件，該頭文件歷史較久，不支持 Module：

通過給 Clang 編譯器定義一個 module.modulemap 文件，在該文件中可以將頭文件映射成模塊：

編譯腳本需要依次編譯 A、ctype、iostream 三個模塊，然后再編譯 main 文件：

首先使用 -fmodule-map-file 參數(shù)，指定一個 module map file，然后通過 -fmodule 指定 map file 中定義的 module，就可以將頭文件編譯成 pcm。main 文件使用 A、iostream 等模塊時，同樣需要使用 fmodule-map-file 參數(shù)指定 mdule map 文件，同時使用 -fmodule 指定依賴的模塊名稱。

注：關(guān)于 Module Map 機制能夠查到的資料較少，有些細節(jié)筆者也未能一一查明，例如：

• 通過 Module Map 將一個頭文件模塊化之后，頭文件中暴露的宏會如何處理？

• 假如頭文件聲明的實體的實現(xiàn)分散在多個 cpp 中，該如何組織編譯？

?Module 與 Namespace?

Module 與 Namespace 是兩個維度的概念，在 Module 中同樣可以導出 Namespace：

總結(jié)

最后，對比最開始提到的頭文件的缺點，模塊機制有以下幾點優(yōu)勢：

• 無需重復編譯：一個模塊的所有接口文件、實現(xiàn)文件，作為一個翻譯單元，一次編譯后生成 pcm，之后遇到 Import 該模塊的代碼，編譯器會從 pcm 中尋找函數(shù)聲明等信息，該特性會極大加快 C++ 代碼的編譯速度。

• 隔離性更好：模塊內(nèi) Import 的內(nèi)容，不會泄漏到模塊外部，除非顯式使用 export Import 聲明。

• 順序無關(guān)：Import 多個模塊，無需關(guān)心這些模塊間的順序。

• 減少冗余與不一致：小的模塊可以直接在單個 cppm 文件中完成實體的導出、定義，但大的模塊依然會把聲明、實現(xiàn)拆分到不同文件。

• 子模塊、Module Partition 等機制讓大模塊、超大模塊的組織方式更加靈活。

• 全局模塊段、Module Map 制使得 Module 與老舊的頭文件交互成為可能。

缺點也有：

• 編譯器支持不穩(wěn)定：尚未有編譯器完全支持 Module 的所有特性、Clang13 支持的 Module Map 特性不一定保留到主干版本。

• 編譯時需要分析依賴關(guān)系、先編譯最基礎(chǔ)的模塊。

• 現(xiàn)有的 C++ 工程需要重新組織 pipline，且尚未出現(xiàn)自動化的構(gòu)建系統(tǒng)，需要人工根據(jù)依賴關(guān)系組構(gòu)建腳本，實施難度巨大。

Module 不能做什么？

• Module 不能實現(xiàn)代碼的二進制分發(fā)，依然需要通過源碼分發(fā) Module。

• pcm 文件不能通用，不同編譯器的 pcm 文件不能通用，同一編譯器不同參數(shù)的 pcm 不能通用。

• 無法自動構(gòu)建，現(xiàn)階段需要人工組織構(gòu)建腳本。

編譯器如何實現(xiàn)對外隱藏 Module 內(nèi)部符號的？

• 在 Module 機制出現(xiàn)之前，符號的鏈接性分為外部連接性（external linkage，符號可在文件之間共享）、內(nèi)部鏈接性（internal linkage，符號只能在文件內(nèi)部使用），可以通過 extern、static 等關(guān)鍵字控制一個符號的鏈接性。

• Module 機制引入了模塊鏈接性(module linkage)，符號可在整個模塊內(nèi)部共享(一個模塊可能存在多個 partition 文件)。

• 對于模塊 export 的符號，編譯器根據(jù)現(xiàn)有規(guī)則（外部連接性）對符號進行名稱修飾(name mangling)。

• 對于 Module 內(nèi)部的符號，統(tǒng)一在符號名稱前面添加 “_Zw” 名稱修飾，這樣鏈接器鏈接時便不會鏈接到內(nèi)部符號。

截至2020.7，三大編譯器對 Module 機制的支持情況：

以上就是本文的全部內(nèi)容，關(guān)于 C++20 的四大特性我們介紹了其一，在后續(xù)的文章中，我們也會陸續(xù)安排另外三大（concept、range、coroutine）的解讀，也歡迎繼續(xù)關(guān)注我們。文中內(nèi)容難免會有疏漏與不足，歡迎留言與我們交流。

?作者介紹?

馬建亭，網(wǎng)易云信資深 C++ 開發(fā)工程師，主要負責網(wǎng)易云信 NERTC SDK 的開發(fā)、維護、重構(gòu)等工作，擁有多年 C++ 客戶端開發(fā)經(jīng)驗，現(xiàn)致力于跨平臺 C++ 開發(fā)。

?相關(guān)推薦閱讀?

• 技術(shù)系列課回顧 | 網(wǎng)易云信線上萬人連麥技術(shù)大揭秘

• 技術(shù)實踐 | Android Flutter 多實例實踐

• 滿贈！折扣！免費送！網(wǎng)易云信年中大促來了！

總結(jié)

以上是生活随笔為你收集整理的技术干货 | C++20 四大特性之一：Module 特性详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。