模板編譯報(bào)錯(cuò)讀不懂真不怪你。C的模板在編譯期展開(kāi)時(shí)編譯器打印錯(cuò)誤的方式天然反人類它不會(huì)像運(yùn)行期調(diào)試器那樣告訴你程序停在命令行斷點(diǎn)當(dāng)前變量長(zhǎng)這樣而是甩給你一長(zhǎng)串以std::開(kāi)頭的類型聲明外加一段in instantiation of的實(shí)例化回溯。你盯著屏幕想找我到底哪寫錯(cuò)了結(jié)果滿屏都是std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar這種恨不得把全家譜都列出來(lái)的類型全名。這兩者的差距就是大多數(shù)人接觸模板元編程時(shí)最大的勸退點(diǎn)。編譯期調(diào)試和運(yùn)行期調(diào)試完全是兩套方法論運(yùn)行期你可以打斷點(diǎn)、看變量、單步走編譯期你只能通過(guò)制造錯(cuò)誤、約束錯(cuò)誤、翻譯錯(cuò)誤來(lái)讓編譯器替你回答問(wèn)題。這篇東西就是把我這些年跟模板編譯期報(bào)錯(cuò)死磕的經(jīng)驗(yàn)整理出來(lái)講講靜態(tài)斷言怎么用才能當(dāng)調(diào)試終端使遞歸模板失控怎么定位類型名太長(zhǎng)怎么給它配個(gè)翻譯器以及多文件場(chǎng)景下模板重定義這類報(bào)錯(cuò)到底該怎么排查。想認(rèn)真學(xué)模板元編程、被SFINAE和偏特化折磨到懷疑人生的朋友這篇應(yīng)該能幫你省下不少查資料的功夫。先說(shuō)明一下這里說(shuō)的模板是C類模板、函數(shù)模板、變量模板這套編譯期實(shí)例化機(jī)制不是前端模板字符串也不是服務(wù)端模板引擎的調(diào)試。1. 編譯期報(bào)錯(cuò)為何勸退人錯(cuò)誤信息結(jié)構(gòu)與模板實(shí)例化的割裂很多人第一次嘗試讀模板編譯錯(cuò)誤時(shí)心態(tài)直接崩掉根源在于他沒(méi)有理解編譯器在編譯模板時(shí)到底經(jīng)歷了什么。普通函數(shù)的編譯錯(cuò)誤很好懂編譯器看到一個(gè)函數(shù)調(diào)用參數(shù)類型對(duì)不上直接報(bào)第幾行參數(shù)不匹配。但模板不一樣。模板本身不是最終代碼它只是一個(gè)生成方案的說(shuō)明書。編譯器在遇到模板實(shí)例化請(qǐng)求時(shí)會(huì)把模板參數(shù)代入生成一份具體的類或函數(shù)然后才能做類型檢查。這個(gè)過(guò)程里任何一步類型不匹配錯(cuò)誤信息都會(huì)包含從最初的實(shí)例化請(qǐng)求到失敗的那個(gè)模板最深處的成員之間的完整鏈條。舉個(gè)例子你在main.cpp里寫了std::vectorint v; v.push_back(hello);表面上看錯(cuò)誤點(diǎn)在push_back調(diào)用。但編譯器實(shí)際報(bào)錯(cuò)時(shí)會(huì)先給出當(dāng)前實(shí)例化鏈main.cpp第3行實(shí)例化std::vectorint然后push_back定義在/usr/include/c/.../vector的某個(gè)頭文件里在那里對(duì)const char*到int的轉(zhuǎn)換失敗。報(bào)錯(cuò)信息的結(jié)構(gòu)大致是三層是什么no matching function for call to std::vectorint::push_back(const char [6])在哪從main.cpp的調(diào)用點(diǎn)到stl_vector.h內(nèi)部定義的展開(kāi)點(diǎn)為什么no known conversion from const char [6] to int運(yùn)行期調(diào)試你可以在任意一行設(shè)斷點(diǎn)觀察那一刻的執(zhí)行狀態(tài)。但編譯期沒(méi)有斷點(diǎn)這個(gè)概念你不能讓模板實(shí)例化到一半停下來(lái)打開(kāi)某個(gè)類型看看里面的成員有哪些。你能做的最接近的事情是想辦法讓某個(gè)關(guān)鍵位置的類型顯形然后根據(jù)編譯器對(duì)這個(gè)顯形結(jié)果的反饋來(lái)推斷。換句話說(shuō)編譯期調(diào)試的核心思路是別指望編譯器給你完整答案你要設(shè)計(jì)一個(gè)個(gè)小實(shí)驗(yàn)讓編譯器在某個(gè)特定位置停下來(lái)把信息吐出來(lái)。這個(gè)思路一旦建立后面所有手段——靜態(tài)斷言、輔助模板、類型名翻譯——其實(shí)都是圍繞它展開(kāi)的。另外還有個(gè)認(rèn)知誤區(qū)要破掉模板報(bào)錯(cuò)信息長(zhǎng)不代表你寫錯(cuò)了N處往往只是第一個(gè)錯(cuò)誤引發(fā)了后續(xù)一堆連鎖反應(yīng)。編譯器在模板實(shí)例化失敗后會(huì)嘗試?yán)^續(xù)檢查別的實(shí)例化路徑但很多報(bào)錯(cuò)其實(shí)是同一根因的重復(fù)輸出。所以調(diào)試模板報(bào)錯(cuò)的第一原則是**只盯著第一條error看后面的error大概率是這條的次生災(zāi)害。**我見(jiàn)過(guò)有人在一條編譯日志里看到五十多個(gè)error以為是五十多個(gè)bug其實(shí)第一條改掉剩下四十九條全部消失。理解了這個(gè)底層機(jī)制再看下面這些調(diào)試手段你會(huì)知道每個(gè)手段分別是針對(duì)是什么在哪為什么中的哪一層。2. 靜態(tài)斷言的正確用法把編譯期當(dāng)成調(diào)試器終端static_assert可能是模板調(diào)試?yán)镒畋坏凸赖墓ぞ?。很多人只拿它做一件事static_assert(std::is_same_vT, int)——檢查類型是不是某個(gè)具體類型。這當(dāng)然沒(méi)問(wèn)題但你要是只會(huì)這么用等于手里有臺(tái)打印機(jī)卻只用來(lái)打hello world。2.1 基礎(chǔ)斷言組合類型謂詞別只會(huì)is_same模板調(diào)試時(shí)最常問(wèn)的問(wèn)題是T到底是什么、T能不能做這件事。C標(biāo)準(zhǔn)庫(kù)提供了大量類型萃取你要學(xué)會(huì)把它們組合起來(lái)形成一句有意義的話。#include type_traits #include string template typename T class Storage { static_assert(std::is_nothrow_move_constructible_vT, Storage requires a nothrow-move-constructible type); public: // ... }; // 使用 Storagestd::string a; // OKstd::string 滿足要求 static_assert(!std::is_same_vint, std::string, int and std::string should be different); // 明確的靜態(tài)斷言這種寫法的好處是斷言信息直接寫成了人話Storage requires a nothrow-move-constructible type。當(dāng)使用者傳入一個(gè)僅支持拷貝構(gòu)造、移動(dòng)構(gòu)造會(huì)拋異常的類型時(shí)編譯錯(cuò)誤里會(huì)有這句話比在一堆static_assert failed的原始表達(dá)里找原因舒服得多。2.2 體檢型斷言在關(guān)鍵實(shí)例化位置栽樁模板庫(kù)里的模板函數(shù)和模板類定義和實(shí)例化點(diǎn)往往相隔甚遠(yuǎn)。你想知道某次實(shí)例化時(shí)某個(gè)類型長(zhǎng)什么樣最直接的辦法是在目標(biāo)位置臨時(shí)加一個(gè)必然失敗的靜態(tài)斷言讓編譯器把類型信息顯示出來(lái)。這里有個(gè)關(guān)鍵工具就是always_false這個(gè)慣用法#include type_traits template typename... struct always_false : std::false_type {}; template typename T void inspect() { // 只要實(shí)例化到這一行就一定觸發(fā)編譯錯(cuò)誤并且打印出 T 的實(shí)際類型 static_assert(always_falseT::value, Inspect point: see T below); } int main() { inspectint(); // error: static assertion failed: Inspect point: see T below // note: in instantiation of function template specialization inspectint requested here }為什么不能直接寫static_assert(false, ...)因?yàn)榉悄０宓膕tatic_assert(false)在模板定義階段就會(huì)被編譯器拒絕不管這個(gè)模板有沒(méi)有被實(shí)例化都會(huì)報(bào)錯(cuò)。而always_falseT是一個(gè)依賴模板參數(shù)的類型只有當(dāng)你真正inspectint()的那一刻always_falseint才會(huì)被實(shí)例化靜態(tài)斷言才會(huì)觸發(fā)。這就實(shí)現(xiàn)了栽樁——你把它放在模板的哪個(gè)函數(shù)哪個(gè)位置它就只在那一次實(shí)例化時(shí)爆炸把當(dāng)時(shí)的類型信息帶出來(lái)。2.3 失配類型的驗(yàn)尸報(bào)告always_false適合顯示當(dāng)前函數(shù)上下文里的類型。但有時(shí)候你只是在某個(gè)表達(dá)式旁邊想確認(rèn)decltype(expr)到底是什么手里又沒(méi)有現(xiàn)成的模板函數(shù)可改這時(shí)候可以用前向聲明技巧逼編譯器寫驗(yàn)尸報(bào)告template typename struct debug_type; // 只聲明不定義 template typename T void f(T x) { // 故意對(duì)不完整類型取 ::value觸發(fā)實(shí)例化失敗 static_assert(debug_typedecltype(x)::value, Type of x is shown in the error); }當(dāng)編譯器試圖實(shí)例化debug_typeint時(shí)發(fā)現(xiàn)它是未定義的不完整類型于是報(bào)錯(cuò)error: implicit instantiation of undefined template debug_typeintint就被打印出來(lái)了。如果表達(dá)式更復(fù)雜比如decltype(std::declvalT() 1)報(bào)錯(cuò)信息里會(huì)直接顯示這個(gè)表達(dá)式推導(dǎo)出的完整類型。我在排查復(fù)雜的表達(dá)式模板、auto返回類型推導(dǎo)問(wèn)題時(shí)這一招幾乎是必用的。2.4 二段式斷言先檢查條件本身再檢查結(jié)果還有一種我特別常用的靜態(tài)斷言用法是針對(duì)約束條件的驗(yàn)證。比如你在寫一個(gè)類型萃取想確認(rèn)T可以被另一個(gè)類型U構(gòu)造template typename T, typename U void construct_from(const U u) { static_assert(std::is_constructible_vT, U, T is not constructible from U); // ... }這種斷言如果失敗編譯器會(huì)告訴你T和U分別是什么你一眼能看出不匹配在哪。但更麻煩的情況是——你調(diào)用了某個(gè)模板函數(shù)它內(nèi)部有一堆這樣的斷言結(jié)果失敗了你卻不知道是哪一個(gè)約束沒(méi)滿足。這時(shí)候我習(xí)慣在調(diào)用點(diǎn)附近先加一層前置斷言來(lái)縮小范圍static_assert(std::is_constructible_vMyType, ArgType, Call site: MyType cannot be built from ArgType); construct_fromMyType(arg);這相當(dāng)于把失敗原因從模板內(nèi)部撈到了調(diào)用點(diǎn)自己身上排查范圍一下就縮小了。我踩過(guò)不少次這種坑模板庫(kù)里十幾個(gè)約束調(diào)用失敗后得翻半天才知道是哪一條沒(méi)滿足。在調(diào)用點(diǎn)加一句前置斷言就是給排查裝了個(gè)縮小鏡。3. 一樁真實(shí)排查多文件里出現(xiàn)的類模板名稱不能重復(fù)是怎么回事靜態(tài)斷言解決的是模板實(shí)例化后的類型對(duì)不對(duì)這一類問(wèn)題。但模板調(diào)試還有另一大類——模板定義層面出了問(wèn)題。比如編譯器直接告訴你類模板名稱不能重復(fù)這屬于典型的定義污染或者合并沖突。我拿一個(gè)真實(shí)項(xiàng)目里遇到的案例完整走一遍排查鏈路。3.1 報(bào)錯(cuò)現(xiàn)場(chǎng)還原當(dāng)時(shí)是一個(gè)用CMake組織的中型C項(xiàng)目編譯某個(gè)大型翻譯單元時(shí)突然冒出一行error: redefinition of templateclass T class Registry緊接著是同文件的另幾行note: previous definition of templateclass T class Registry was here我第一反應(yīng)是同一個(gè)頭文件被include了兩次而include guard失效了。但仔細(xì)一看報(bào)錯(cuò)的兩個(gè)位置距離非常遠(yuǎn)一個(gè)在registry.hpp另一個(gè)在legacy_registry.hpp。兩個(gè)文件里各自定義了一個(gè)同名同簽名的template typename T class Registry并且被同一個(gè)翻譯單元同時(shí)包含自然撞車。3.2 排查鏈路先做減法再追沖突源這個(gè)問(wèn)題的正確排查順序不是先去改模板內(nèi)容而是搞清楚這兩個(gè)文件為什么同時(shí)出現(xiàn)在編譯單元里。我的做法是第一步用預(yù)處理命令把單個(gè)翻譯單元展開(kāi)看這兩個(gè)模板到底是從哪些路徑被拉進(jìn)來(lái)的g -stdc20 -E src/main.cpp | grep -n class Registry | head -50預(yù)處理輸出會(huì)直接列出所有頭文件展開(kāi)后的內(nèi)容。看輸出里class Registry前后的#line指令能快速定位它們分別來(lái)自哪個(gè)文件、被誰(shuí)include。這一步基本能確認(rèn)不是同一個(gè)文件被重復(fù)包含而是兩個(gè)不同文件在同一個(gè)作用域分別定義。第二步追include關(guān)系?？磎ain.cpp的#include列表發(fā)現(xiàn)它間接包含了core/registry.hpp和legacy/registry.hpp而這兩條路徑最終都匯聚到core/Engine.hpp——legacy/registry.hpp是某個(gè)舊模塊的遺留物被另一個(gè)公共頭文件順手帶出來(lái)沒(méi)人注意到它。第三步檢查命名空間。發(fā)現(xiàn)兩個(gè)模板都聲明在全局命名空間里沒(méi)有任何namespace包裹。這種兩個(gè)同名模板在全局作用域撞車的情況在項(xiàng)目規(guī)模變大后非常容易發(fā)生尤其是從不同子模塊合并代碼時(shí)命名習(xí)慣不統(tǒng)一就會(huì)中招。3.3 修復(fù)與預(yù)防我當(dāng)時(shí)沒(méi)有直接改legacy_registry.hpp里的模板名——因?yàn)檫@個(gè)舊模板還有不少調(diào)用點(diǎn)全局替換風(fēng)險(xiǎn)太大。而是給新模板加了命名空間把Registry放進(jìn)core::同時(shí)用using core::Registry;在公共頭文件里做顯式導(dǎo)出。這樣舊代碼繼續(xù)用Registry新代碼可以用core::Registry兩套定義不再?zèng)_突。預(yù)防方面我在CI腳本里加了一條編譯期掃描grep -rn ^template.*class Registry src/出現(xiàn)跨文件重復(fù)定義時(shí)發(fā)警告。更根本的措施是規(guī)定新增模板一律進(jìn)入命名空間禁止在全局作用域定義類模板。踩過(guò)這次坑之后我的體會(huì)是**類模板名稱不能重復(fù)這類報(bào)錯(cuò)本質(zhì)是項(xiàng)目管理問(wèn)題不是模板語(yǔ)法問(wèn)題。**排查時(shí)不要盯著模板定義本身看半天先問(wèn)為什么同一個(gè)作用域里會(huì)有兩份定義。用預(yù)處理展開(kāi)定位include來(lái)源、用git log追溯模板的引入時(shí)間比在編輯器里反復(fù)看代碼有效得多。4. 遞歸模板失控編譯期死循環(huán)的定位與止損如果說(shuō)類模板名稱不能重復(fù)是模板調(diào)試?yán)锏捻?xiàng)目管線問(wèn)題那么遞歸模板失控就是更純粹的元編程問(wèn)題。寫遞歸模板的時(shí)候終止條件稍有疏忽編譯器就會(huì)陷入無(wú)限展開(kāi)但它不會(huì)一直跑下去——它會(huì)達(dá)到遞歸深度上限后給你一屏報(bào)錯(cuò)。4.1 基礎(chǔ)癥狀深度上限與實(shí)例化回溯看一個(gè)典型的錯(cuò)誤template size_t N struct Loop { static constexpr size_t value LoopN 1::value; }; // 實(shí)例化觸發(fā) constexpr size_t v Loop0::value;用GCC編譯會(huì)得到error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth to increase the maximum)用Clang編譯會(huì)得到error: recursive template instantiation exceeded maximum depth of 1024這其實(shí)是編譯器的止損機(jī)制在起作用。模板遞歸沒(méi)有真正無(wú)限運(yùn)行它有深度上限到了上限就主動(dòng)報(bào)錯(cuò)退出。但是如果遞歸邏輯本身特別深比如遞歸鏈長(zhǎng)達(dá)幾千層或者終止條件在很深層才生效那么你看到的回溯信息會(huì)非常長(zhǎng)長(zhǎng)到關(guān)鍵的起點(diǎn)被淹沒(méi)在內(nèi)存里。4.2 定位方法把終止條件檢查提前到每一層肉眼盯著回溯找哪一層斷了效率太低。我的做法是在遞歸模板的每一層都加一個(gè)靜態(tài)斷言讓編譯器在斷鏈點(diǎn)當(dāng)場(chǎng)爆出來(lái)而不是一路遞歸到深度上限才報(bào)錯(cuò)。比如寫階乘模板最常見(jiàn)的失誤是特化寫錯(cuò)或者沒(méi)寫template size_t N struct Factorial { // 在每次遞歸前檢查N 不能為 0如果為 0 說(shuō)明終止特化沒(méi)有覆蓋到 static_assert(N 0, Factorial recursion reached 0 without a specialization); static constexpr size_t value N * FactorialN - 1::value; }; template struct Factorial1 { static constexpr size_t value 1; };如果哪天有人誤寫了Factorial1的特化卻忘了寫Factorial0那么實(shí)例化Factorial0時(shí)第一個(gè)靜態(tài)斷言會(huì)立刻觸發(fā)報(bào)錯(cuò)信息直接顯示static assertion failed: Factorial recursion reached 0 without a specialization。你不需要去翻幾百層回溯一眼就知道問(wèn)題出在終止條件缺了0這一層。4.3 定位技巧二分法縮小初始參數(shù)有時(shí)候遞歸模板沒(méi)有明顯的斷鏈點(diǎn)而是某個(gè)參數(shù)計(jì)算路徑錯(cuò)誤導(dǎo)致遞歸鏈非常長(zhǎng)且慢慢偏離預(yù)期。比如類型列表展開(kāi)某個(gè)參數(shù)包解包錯(cuò)誤導(dǎo)致N的遞減失效每次每層N都是同一個(gè)值最終撞上深度上限。這種情況下我習(xí)慣用二分法來(lái)縮小排查范圍。假設(shè)正常應(yīng)該N100終止現(xiàn)在報(bào)錯(cuò)說(shuō)深度上限1024那我會(huì)臨時(shí)把初始值改成N500編譯一次如果也爆改成N250如果沒(méi)爆改成N375……通過(guò)調(diào)整初始N值找到開(kāi)始爆炸的臨界點(diǎn)再對(duì)照代碼里的終止條件一般能很快定位到是哪一步遞推沒(méi)有改變遞歸參數(shù)。這種方法本質(zhì)上是把編譯期當(dāng)成了一個(gè)可控實(shí)驗(yàn)臺(tái)——你不必一次猜中而是通過(guò)修改實(shí)驗(yàn)參數(shù)觀察編譯結(jié)果來(lái)逼近真相。4.4 止損技巧臨時(shí)注釋大段實(shí)例化請(qǐng)求在大項(xiàng)目里遇到遞歸模板失控還有一個(gè)實(shí)用技巧注釋掉與當(dāng)前調(diào)試無(wú)關(guān)的模板實(shí)例化請(qǐng)求單獨(dú)構(gòu)造一個(gè)最小測(cè)試文件。比如你的大項(xiàng)目里同時(shí)實(shí)例化了十幾個(gè)不同類型的遞歸模板報(bào)錯(cuò)信息混在一起完全沒(méi)法看那就新建一個(gè)min_test.cpp只保留一個(gè)出問(wèn)題的實(shí)例化用單獨(dú)的編譯命令跑。g -stdc20 -fsyntax-only min_test.cpp為什么這么干因?yàn)榫幾g器在飛快的報(bào)錯(cuò)輸出里每條error的上下文可能被之前的幾百條note淹沒(méi)單獨(dú)跑最小測(cè)試能大大降低信息噪度。我在處理模板庫(kù)崩潰類問(wèn)題時(shí)幾乎總是先在最小文件里復(fù)現(xiàn)再回到大項(xiàng)目里逐步放開(kāi)。這是一個(gè)能救命的習(xí)慣。5. 給編譯錯(cuò)誤配一套人話翻譯器類型改名、截?cái)嗯c別名輸出前面講的所有調(diào)試手段最后都繞不開(kāi)一個(gè)問(wèn)題報(bào)錯(cuò)信息里類型名太長(zhǎng)長(zhǎng)到人類肉眼根本不想讀。尤其是STL容器嵌套、迭代器、函數(shù)對(duì)象這些類型一個(gè)std::unordered_mapstd::string, std::vectorstd::functionvoid(int)就能刷掉一整行。長(zhǎng)類型名不是在增加信息量而是在消耗你的耐心。5.1 用別名折疊類型鏈在庫(kù)代碼內(nèi)部不要吝嗇使用using別名。一個(gè)常用的習(xí)慣是給模板庫(kù)的外部接口定義短別名讓報(bào)錯(cuò)信息里的核心類型變短template typename T using Vec std::vectorT; template typename Key, typename Value using Table std::unordered_mapKey, Value; template typename T using Handler std::functionvoid(T);這樣出錯(cuò)時(shí)報(bào)錯(cuò)信息里出現(xiàn)的就不再是std::vectorstd::functionvoid(int) 這種三層嵌套而是VecHandlerint。雖然最后還是有一層包裹但可讀性提升是質(zhì)變的。我實(shí)測(cè)過(guò)一個(gè)長(zhǎng)度接近100字符的STL類型鏈加別名后變成20個(gè)字符左右排查速度提升不止一倍。5.2 讓報(bào)錯(cuò)信息帶標(biāo)題針對(duì)某些復(fù)雜的實(shí)例化鏈我還會(huì)用診斷填充的技巧在關(guān)鍵模板位置插入一段帶大量換行和標(biāo)記的靜態(tài)斷言讓報(bào)錯(cuò)信息在IDE的輸出窗口里形成視覺(jué)分界線方便肉眼快速定位。template int struct debug_mark { static_assert(std::is_same_vint, char, \n\n\n 調(diào)試分界線到這里檢查類型 \n\n\n); };當(dāng)然這個(gè)技巧只適合臨時(shí)調(diào)試用提交代碼前要?jiǎng)h掉。但它的價(jià)值是實(shí)實(shí)在在的當(dāng)你面對(duì)一屏幾百行報(bào)錯(cuò)時(shí)一個(gè)帶大標(biāo)題的斷言就像是在垃圾堆里插了一面旗子一眼就能看到。5.3 用type_name翻譯器打印推導(dǎo)類型另一個(gè)我強(qiáng)烈推薦的小工具是運(yùn)行時(shí)type_nameT()函數(shù)。它在運(yùn)行期打印出模板實(shí)參的實(shí)際類型名對(duì)排查重載決議、模板推導(dǎo)歧義特別有用而且實(shí)現(xiàn)起來(lái)不復(fù)雜#include string_view template typename T constexpr std::string_view type_name() { #if defined(__clang__) std::string_view name __PRETTY_FUNCTION__; name.remove_prefix(name.find(T ) 4); name.remove_suffix(name.size() - name.find(;)); #elif defined(__GNUC__) std::string_view name __PRETTY_FUNCTION__; name.remove_prefix(name.find(T ) 4); name.remove_suffix(name.size() - name.find(;)); #elif defined(_MSC_VER) std::string_view name __FUNCSIG__; name.remove_prefix(name.find(T ) 4); name.remove_suffix(name.size() - name.find(;)); #endif return name; }不同編譯器下__PRETTY_FUNCTION__的輸出格式有差異這個(gè)函數(shù)需要根據(jù)你用的編譯器做微調(diào)。我一般會(huì)在寫模板庫(kù)時(shí)順手放進(jìn)一個(gè)公共頭文件里調(diào)試時(shí)直接std::cout type_namedecltype(x)() std::endl;非常方便。5.4 用候選模板清單輔助排查重載失敗當(dāng)函數(shù)模板因?yàn)镾FINAE被排除導(dǎo)致no matching function時(shí)編譯器往往只會(huì)給你一句冷冰冰的候選函數(shù)不可用卻不告訴你每個(gè)候選到底哪里不匹配。這時(shí)候有一個(gè)實(shí)用技巧給每個(gè)候選模板加一個(gè)帶always_false的輔助斷言把候選模板列出到報(bào)錯(cuò)信息里。template typename T void process(T) { static_assert(always_falseT::value, Candidate 1: generic process called. T see below); } template typename T void process(std::vectorT) { static_assert(always_falseT::value, Candidate 2: vector process called. T see below); }當(dāng)重載決議選錯(cuò)分支時(shí)你會(huì)看到哪一版被調(diào)用、實(shí)際的T是什么。這比單純看no matching function有用得多因?yàn)樗苯痈嬖V你編譯器最終選了誰(shuí)以及為什么是它。6. 編譯器選項(xiàng)、規(guī)范約束與標(biāo)準(zhǔn)庫(kù)差異進(jìn)階調(diào)試支援模板調(diào)試不只是寫代碼層面的技巧編譯器本身也提供了一些影響調(diào)試體驗(yàn)的選項(xiàng)以及不同標(biāo)準(zhǔn)庫(kù)實(shí)現(xiàn)帶來(lái)的差異這些都可以在你排查時(shí)派上用場(chǎng)。6.1 幾個(gè)常用的編譯選項(xiàng)對(duì)比GCC: -fmax-errorsN 最多顯示N個(gè)錯(cuò)誤防止刷屏 -ftemplate-backtrace-limitN 限制模板實(shí)例化回溯深度默認(rèn)10 -ftemplate-depthN 提高模板遞歸深度上限 Clang: -ferror-limitN 最多顯示N個(gè)錯(cuò)誤 -ftemplate-backtrace-limitN 控制模板實(shí)例化回溯深度顯示 -fdiagnostics-show-template-tree 以樹(shù)狀結(jié)構(gòu)顯示復(fù)雜模板參數(shù)我實(shí)際使用中最常用的組合是先把-fmax-errors或-ferror-limit設(shè)為1強(qiáng)制自己只看第一條錯(cuò)誤在需要觀察遞歸模板回溯時(shí)把-ftemplate-backtrace-limit調(diào)大讓編譯器完整打印實(shí)例化鏈在項(xiàng)目編譯速度允許的情況下偶爾用-fdiagnostics-show-template-tree看看復(fù)雜模板參數(shù)是怎么嵌套的。6.2 C20約束比SFINAE的報(bào)錯(cuò)友好在哪里C20的requires和概念concept出來(lái)后模板約束的報(bào)錯(cuò)體驗(yàn)確實(shí)提升了一大截。以前用SFINAE寫約束類型不滿足條件時(shí)報(bào)錯(cuò)信息常常指向一串enable_if的深層展開(kāi)完全沒(méi)人能讀懂。有了概念編譯器會(huì)直接告訴你約束失敗類型T不滿足ConceptName所要求的一組表達(dá)式。但要注意一點(diǎn)概念本身如果寫得不好報(bào)錯(cuò)照樣讓人頭大。比如概念里塞了一長(zhǎng)串復(fù)雜要求失敗時(shí)編譯器打印because ... does not satisfy ...但那個(gè)...如果是一長(zhǎng)串嵌套表達(dá)式讀起來(lái)還是要命。所以自定義概念時(shí)盡量拆成多個(gè)小概念再組合這樣報(bào)錯(cuò)能精確定位到具體哪個(gè)子約束失敗template typename T concept CanAdd requires(T a, T b) { a b; }; template typename T concept CanMultiply requires(T a, T b) { a * b; }; template typename T concept Arithmetic CanAddT CanMultiplyT;這樣如果某個(gè)類型只支持加法不支持乘法報(bào)錯(cuò)會(huì)明確說(shuō)它不滿足CanMultiply而不是籠統(tǒng)地不滿足Arithmetic。6.3 libstdc和libc的報(bào)錯(cuò)差異同樣一份包含STL模板的代碼用GCC默認(rèn)libstdc和Clang配libc編譯報(bào)錯(cuò)信息的可讀性會(huì)有明顯差別。libstdc的報(bào)錯(cuò)信息里大量使用std::__cxx11::這種內(nèi)部命名空間前綴類型名極長(zhǎng)libc用的是std::__1::前綴長(zhǎng)度稍短但也沒(méi)有本質(zhì)性改善。真正的差異在于libstdc的某些模板實(shí)現(xiàn)更依賴內(nèi)部輔助類型導(dǎo)致報(bào)錯(cuò)鏈更深。我在調(diào)試復(fù)雜STL嵌套代碼時(shí)有時(shí)會(huì)故意切換標(biāo)準(zhǔn)庫(kù)實(shí)現(xiàn)來(lái)看同一個(gè)錯(cuò)誤的兩種呈現(xiàn)方式。比如一個(gè)std::bind綁定參數(shù)類型錯(cuò)誤GCC可能會(huì)報(bào)出三層lambda/function_helper類型libc可能兩層就能說(shuō)完。這不是標(biāo)準(zhǔn)庫(kù)誰(shuí)好誰(shuí)壞的問(wèn)題而是換一個(gè)視角看同一個(gè)bug往往有意想不到的收獲。7. 幾條保命經(jīng)驗(yàn)關(guān)于編譯期調(diào)試的邊界寫到這里我把自己這些年跟模板編譯期調(diào)試打交道積累下來(lái)的幾條經(jīng)驗(yàn)總結(jié)一下。這些不是教科書上的理論是實(shí)實(shí)在在踩過(guò)坑之后留下的條件反射。**一次只追一條報(bào)錯(cuò)。**模板報(bào)錯(cuò)連鎖反應(yīng)極其嚴(yán)重一條根因能衍生出幾十條看似不同的錯(cuò)誤。我給自己定的規(guī)矩是-fmax-errors1強(qiáng)制只看第一條。修完以后重新編譯如果還有錯(cuò)大概率是下一個(gè)獨(dú)立問(wèn)題如果第一條修好了后面全好說(shuō)明就是連鎖反應(yīng)。**最小復(fù)現(xiàn)優(yōu)于在大項(xiàng)目里硬搜。**不管遇到多么詭異的模板編譯問(wèn)題我都會(huì)先嘗試在一個(gè)幾十行的新文件里復(fù)現(xiàn)。復(fù)現(xiàn)不了說(shuō)明問(wèn)題跟項(xiàng)目結(jié)構(gòu)、include順序、宏定義有關(guān)復(fù)現(xiàn)得了調(diào)試空間一下就從整個(gè)項(xiàng)目縮小到一個(gè)文件。這個(gè)習(xí)慣幫我排掉了至少一半的疑難雜癥。**修改模板后一定要清理舊構(gòu)建產(chǎn)物。**增量編譯是模板調(diào)試的隱形殺手。模板實(shí)例化的結(jié)果會(huì)被緩存在目標(biāo)文件和預(yù)編譯頭里你改了一個(gè)模板定義但某些翻譯單元可能還在用舊的實(shí)例化結(jié)果。我在一個(gè)項(xiàng)目里遇到過(guò)明明改了模板卻編譯不出對(duì)應(yīng)錯(cuò)誤的怪事折騰半天發(fā)現(xiàn)是CMake增量構(gòu)建把某個(gè).cpp當(dāng)成沒(méi)變化給跳過(guò)了。遇到行為不一致時(shí)先clean再編譯永遠(yuǎn)是最快的排查手段。**善用預(yù)編譯頭的風(fēng)險(xiǎn)意識(shí)。**項(xiàng)目開(kāi)了PCH預(yù)編譯頭之后模板報(bào)錯(cuò)的位置可能被拉得更遠(yuǎn)因?yàn)楣材０宥急蝗M(jìn)了PCH編譯器在報(bào)錯(cuò)時(shí)會(huì)更容易迷失在大量早已展開(kāi)的模板實(shí)例化記錄里。遇到模板報(bào)錯(cuò)特別難定位時(shí)我偶爾會(huì)臨時(shí)關(guān)掉PCH編譯一次看報(bào)錯(cuò)是否更清晰。這個(gè)方法不總能奏效但值得一試。**別把編譯期調(diào)試拖到深夜。**這聽(tīng)起來(lái)像玩笑但我認(rèn)真說(shuō)模板報(bào)錯(cuò)需要極強(qiáng)的耐心和注意力狀態(tài)稍微不好就容易在一個(gè)無(wú)關(guān)緊要的細(xì)節(jié)上繞幾個(gè)小時(shí)。實(shí)在憋不出來(lái)就睡一覺(jué)第二天再回來(lái)經(jīng)常十分鐘就看出問(wèn)題在哪。這不是玄學(xué)是切換思維模式帶來(lái)的效率提升。**保存報(bào)錯(cuò)快照。**調(diào)試模板問(wèn)題時(shí)每改一次代碼編譯器輸出就可能完全變樣。我習(xí)慣把關(guān)鍵報(bào)錯(cuò)完整復(fù)制到臨時(shí)文件里留底然后對(duì)照修改前后報(bào)錯(cuò)的差異來(lái)理解編譯器行為。這比靠記憶判斷上次報(bào)的是什么可靠多了。**認(rèn)識(shí)邊界。**同樣一個(gè)模板代碼有人用Clang編譯通過(guò)有人用GCC編譯報(bào)錯(cuò)或者反過(guò)來(lái)這不是編譯器的錯(cuò)是代碼可移植性存在問(wèn)題。模板調(diào)試的終極目標(biāo)不是讓某一種編譯器閉嘴而是讓代碼在不同編譯器和標(biāo)準(zhǔn)庫(kù)下的行為都可預(yù)測(cè)。編譯期調(diào)試的終點(diǎn)是你對(duì)模板的實(shí)例化過(guò)程有了足夠清晰的把握能把運(yùn)行時(shí)才發(fā)現(xiàn)的問(wèn)題提前成編譯期就被抓住。模板編譯期調(diào)試確實(shí)有門檻但它不是玄學(xué)。理解編譯器報(bào)錯(cuò)的結(jié)構(gòu)、會(huì)用靜態(tài)斷言設(shè)計(jì)實(shí)驗(yàn)、掌握定位遞歸失控的方法、懂得給類型名做翻譯這幾件事做到位面對(duì)絕大多數(shù)模板報(bào)錯(cuò)你都能有條不紊地拆解。希望這篇經(jīng)驗(yàn)對(duì)你有用少走點(diǎn)我當(dāng)年走過(guò)的彎路。