C模板一直是我學(xué)習(xí)之路上繞不過去的一座山。寫這篇學(xué)習(xí)筆記之前我已經(jīng)在項目里被模板編譯錯誤折磨過好多次——明明照著文檔寫了編譯器就是看不懂我的代碼。后來我換了個思路去理解它模板根本不是“帶類型的函數(shù)”而是一套讓類型作為參數(shù)參與編譯的代碼生成機制。想通這一點之后之前那些報錯突然就變得有跡可循了。這篇文章可以看成我重新整理過的C模板學(xué)習(xí)筆記從函數(shù)模板和類模板的基礎(chǔ)語法開始一路講到特化、變參模板、模板元編程再到C20的Concept。適合兩類人讀一是剛開始接觸模板、想系統(tǒng)建立概念的初學(xué)者二是寫過一點模板代碼但經(jīng)常被編譯錯誤卡住、想提升排查能力的人。我會把每一部分都配合真實可運行的代碼片段順帶分享一些我在實際開發(fā)中被坑過的地方。1. 模板到底解決了什么問題從重復(fù)代碼到類型參數(shù)化1.1 一段讓我決定認(rèn)真學(xué)模板的重復(fù)代碼兩年前我在某個內(nèi)部工具項目里寫過一段“三胞胎”代碼。需求很簡單求兩個值里的較大者但調(diào)用方有時傳int有時傳double有時傳std::string。我當(dāng)時的做法是完全復(fù)制粘貼改一改參數(shù)類型和函數(shù)名像這樣int max_int(int a, int b) { return a b ? a : b; } double max_double(double a, double b) { return a b ? a : b; } std::string max_string(const std::string a, const std::string b) { return a b ? a : b; }三個函數(shù)邏輯一模一樣只是類型不同。更麻煩的是后來需求變了比較規(guī)則從“大于”改成“絕對值更大”我就要同步修改三處代碼漏改一處線上行為就會出現(xiàn)詭異的不一致。那段時間我深刻體會到一個道理重復(fù)代碼的維護(hù)成本是乘積增長的而不只是求和。真正讓我下定決心啃模板的就是這一堆不斷擴散的“三胞胎”。1.2 模板的“編譯期鴨子類型”實例化才是核心用模板改寫上面的問題代碼量立刻縮成一份template typename T T my_max(const T a, const T b) { return a b ? a : b; }關(guān)鍵在于理解上面的my_max并不是一個真正的函數(shù)它只是一份“函數(shù)藍(lán)圖”。編譯器看到my_max(1, 2)時會用int替換掉模板參數(shù)T生成一份針對int的真實函數(shù)看到my_max(1.5, 2.5)時再生成一份針對double的。這個過程叫模板實例化發(fā)生在編譯期運行期完全不感知模板的存在。我習(xí)慣用模具來類比模板是模具本身實例化出來的函數(shù)才是被沖壓出的零件。同一個模具改變原材料類型就能做出不同材質(zhì)但形狀相同的零件。這個理解幫我解決了很多疑惑——比如為什么模板類可以接受那些只支持部分操作的類型因為成員函數(shù)是按需實例化的你沒用到某個成員函數(shù)編譯器就不會去檢查它內(nèi)部的運算合不合法。1.3 模板代碼與普通代碼的三點不同在實際工程里模板代碼給人的“脾氣”和普通函數(shù)很不一樣我總結(jié)了三條最重要的差異第一運行期開銷為零。模板實例化在編譯期完成生成的是普通函數(shù)沒有虛函數(shù)那樣的間接跳轉(zhuǎn)沒有額外的運行時類型信息。作為對比如果用基類指針加虛函數(shù)實現(xiàn)類似效果運行期每一次調(diào)用都要查虛函數(shù)表。第二錯誤往往出現(xiàn)在使用處而不是定義處。模板定義本身經(jīng)常是“法外之地”比如上面my_max要求類型支持operator。你把這個模板定義放在頭文件里編譯器不會立刻報錯只有在某個使用處傳入一個不支持operator的類型時編譯器才會把長長的實例化調(diào)用鏈甩到你臉上。第三定義必須可見。普通函數(shù)可以聲明在頭文件、定義在源文件鏈接器最后把它們拼起來模板不行因為實例化需要看到完整定義。很多新手第一次寫模板習(xí)慣性地把實現(xiàn)放在.cpp里結(jié)果一鏈接變成一堆“undefined reference”這是模板學(xué)習(xí)的第一個經(jīng)典大坑。這三條差異構(gòu)成了理解后面所有內(nèi)容的基礎(chǔ)。我見過太多人糾結(jié)模板語法本身卻忽略了模板的“編譯期代碼生成”本質(zhì)導(dǎo)致遇到報錯時無從下手。2. 函數(shù)模板與類模板入門第一步的關(guān)鍵細(xì)節(jié)2.1 函數(shù)模板的參數(shù)推導(dǎo)與顯式指定函數(shù)模板最讓人舒爽的一點是大部分時候不需要你手動指定類型編譯器會自動推導(dǎo)模板參數(shù)auto v1 my_max(1, 2); // T推導(dǎo)為int auto v2 my_max(1.5, 2.5); // T推導(dǎo)為double auto v3 my_max(a, z); // T推導(dǎo)為char但推導(dǎo)并不是萬能的。我踩過的第一個坑是調(diào)用my_max(1, 2.5)時編譯器直接報錯“template argument deduction failed”。原因是模板參數(shù)T同時出現(xiàn)在const T a和const T b兩個位置編譯器遇到int和double兩種實參時無法確定T到底該選哪個。這時候有兩個選擇顯式指定模板參數(shù)讓int隱式轉(zhuǎn)換成double或者修改模板讓兩個參數(shù)接受不同類型。auto v my_maxdouble(1, 2.5); // 顯式指定T為double顯式指定模板參數(shù)的一個常見場景是函數(shù)參數(shù)和返回值類型有關(guān)聯(lián)但又不完全能從參數(shù)推導(dǎo)出來比如想要返回值類型和某個參數(shù)類型不同時。另一個容易忽略的規(guī)則形如const T的參數(shù)推導(dǎo)時T剝掉引用和頂層const。比如傳一個const int進(jìn)去T推導(dǎo)為int而不是const int。這個細(xì)節(jié)在涉及類型萃取和完美轉(zhuǎn)發(fā)時會變得非常重要建議一開始就有意識地去注意。2.2 類模板的靜態(tài)成員與友元函數(shù)三個容易混淆的點類模板的語法本身并不復(fù)雜無非是把類變成“模具”template typename T class Box { public: static int count; T value; void print() const; }; template typename T int BoxT::count 0;但有三個點我直到實際寫代碼時才真正理解第一個是靜態(tài)成員屬于每個實例。Boxint和Boxdouble各自擁有一份獨立的count因為它們本質(zhì)上是兩個不同的類。你可以在Boxint里累加計數(shù)Boxdouble::count依然是0兩者互不影響。第二個是成員函數(shù)按需實例化。如果某個類型可以構(gòu)造出Box但print()內(nèi)部調(diào)用了這個類型不支持的接口只要整個程序里沒有調(diào)用過Box該類型::print()編譯就能通過。這種“懶加載”特性在泛型約束不足的時候很危險——你可能以為所有類型都支持某個操作結(jié)果撐到運行時才炸。第三個是友元聲明用法特殊。在類模板里聲明友元函數(shù)模板要么用friend void func(T);聲明依賴模板參數(shù)的友元要么用template typename U friend void func(U);聲明一個獨立的友元模板。寫錯的情況下你會得到一堆“鏈接錯誤”或者“重復(fù)聲明”的奇怪報錯。2.3 為什么模板的聲明和定義不能分開放這個問題被問過無數(shù)次也是我最早踩的坑之一。普通函數(shù)可以這樣寫// foo.h int add(int a, int b); // foo.cpp int add(int a, int b) { return a b; }編譯時使用add的源文件只要看到聲明就生成調(diào)用代碼至于定義在哪鏈接器負(fù)責(zé)去找。模板不一樣編譯器在需要實例化template typename T T my_max(...)的時候必須看到模板的完整定義才能往里填入T并生成代碼。如果頭文件里只有聲明調(diào)用處只知道“有這么個模板”卻不知道函數(shù)體是什么編譯器就只能放棄把問題留給鏈接器于是出現(xiàn)一堆完全看不懂的undefined reference。解決方案主要有兩種。最常用的是把模板實現(xiàn)也寫在頭文件里這也是標(biāo)準(zhǔn)庫一直以來的做法另一種是在源文件里顯式實例化比如// template_impl.cpp template int my_maxint(const int, const int); template double my_maxdouble(const double, const double);這相當(dāng)于提前把指定類型的實例生成好鏈接器就能找到定義。但顯式實例化的缺點也很明顯每個需要用到的類型都得手寫一遍一旦類型多起來維護(hù)成本比重復(fù)代碼還可怕。所以絕大部分項目都會選擇第一種“頭文件內(nèi)定義”的方式。3. 模板特化與偏特化編譯器在分支路口如何做選擇3.1 全特化的寫法與適用場景模板實例化時編譯器默認(rèn)是用一個統(tǒng)一“模具”生成代碼。但某些類型可能有更好的實現(xiàn)方式這時就可以為特定類型開小灶這就是全特化。比如前面那個my_max遇到const char*這種C風(fēng)格字符串如果用默認(rèn)的operator去比較比的是指針地址而不是字符串內(nèi)容結(jié)果完全不符合直覺。這時候可以寫一個全特化版本template const char* my_maxconst char*(const char* const a, const char* const b) { return std::strcmp(a, b) 0 ? a : b; }全特化的關(guān)鍵字是template 后面跟一個完全確定類型的函數(shù)或類定義。編譯器在為const char*做實例化時會優(yōu)先找到這個特化版本而不是通用模板。我當(dāng)時的理解是通用模板是默認(rèn)工廠流程全特化是給特定訂單單獨開了一條生產(chǎn)線。不過這里必須提醒一句函數(shù)模板的全特化其實很容易被忽略尤其在存在函數(shù)重載的時候。編譯器選擇順序是先看非模板函數(shù)再看模板特化最后才看模板實例化。如果項目中同時存在一個同名同參的非模板函數(shù)和一個全特化版本非模板函數(shù)往往被優(yōu)先選中這個行為常常讓人困惑。所以我在實踐中更傾向于用函數(shù)重載而不是函數(shù)模板全特化但類模板沒有重載這回事只能特化。3.2 類模板偏特化指針、引用與const的幾種典型偏特化類模板只有全特化和偏特化沒有“重載”。偏特化是指保留部分模板參數(shù)只對某一種模式做專門處理。最常見的應(yīng)用場景是針對指針類型、引用類型、const類型做差異處理。template typename T class Wrapper { public: T data; }; // 針對指針類型的偏特化 template typename T class WrapperT* { public: T* ptr; }; // 針對const類型的偏特化 template typename T class Wrapperconst T { public: T value; // 注意這里T本身剝掉了const };偏特化的本質(zhì)是“模式匹配”。WrapperT*匹配任何指針類型Wrapperconst T匹配任何const類型。編譯器會按匹配程度選一個最合適版本比如Wrapperconst int*既可以被WrapperT*匹配Tconst int也可以被Wrapperconst T匹配Tint*但最終選擇時部分特化與參數(shù)模式的貼合程度會被比較通常T*更貼合因為外面一層是指針且內(nèi)部是const int。這里有個細(xì)節(jié)我原來常弄混偏特化只能用于類模板不能用于函數(shù)模板。函數(shù)模板想要類似效果應(yīng)該用重載。所以如果有人試圖給函數(shù)模板寫template typename T void funcT*(T*)這樣的偏特化語法編譯器會直接拒絕。3.3 特化與重載的優(yōu)先級一個讓我調(diào)試到崩潰的例子有一次我在項目里給一個工具庫寫了這樣的代碼template typename T void handle(const T value) { std::cout generic std::endl; } template void handleint(const int value) { std::cout int specialization std::endl; } void handle(const int value) { std::cout non-template overload std::endl; }調(diào)用handle(42)時我滿心以為輸出的是int specialization結(jié)果控制臺打印出來的是non-template overload。查了好半天才發(fā)現(xiàn)編譯器在選擇重載時非模板版本優(yōu)先于模板特化版本。這條規(guī)則我后來在標(biāo)準(zhǔn)條款里確認(rèn)過如果非模板函數(shù)和模板特化都能匹配非模板函數(shù)優(yōu)先。這件事給我的教訓(xùn)是不要試圖用函數(shù)模板特化去“覆蓋”重載決議它的行為既不直觀又容易讓維護(hù)者誤會。函數(shù)模板想針對特定類型做區(qū)分正確姿勢是寫一個更特化的函數(shù)重載或者用后面會講到的if constexpr/概念約束。類模板特化才是干凈利落的解決方案。4. 變參模板與折疊表達(dá)式簡化重復(fù)代碼的實用工具4.1 參數(shù)包展開的三種方式變參模板variadic templates是我學(xué)會之后覺得“真香”的特性。它允許模板接受任意數(shù)量、任意類型的參數(shù)。C11引入時主要是為了配合完美轉(zhuǎn)發(fā)實現(xiàn)工廠函數(shù)后來C17折疊表達(dá)式讓這個語法又好寫了非常多。先看最經(jīng)典的遞歸展開方式。要打印任意個參數(shù)可以這樣void print_all() { // 遞歸終止函數(shù)空參數(shù)包時結(jié)束 } template typename T, typename... Args void print_all(const T first, const Args... rest) { std::cout first ; print_all(rest...); // 每次剝掉一個參數(shù) }typename... Args聲明一個參數(shù)包Args... rest在函數(shù)參數(shù)列表中表示一組參數(shù)。遞歸展開每次取出第一個參數(shù)剩下的繼續(xù)遞歸直到參數(shù)包為空時調(diào)用無參重載。這是最直觀的展開方式邏輯清晰但每層遞歸都要生成一個新模板實例編譯代價略高。第二種方式是用初始化列表配合逗號表達(dá)式一次性展開template typename... Args void print_all_init(const Args... args) { (void)std::initializer_listint{ (std::cout args , 0)... }; }這里的(std::cout args , 0)是個逗號表達(dá)式先執(zhí)行打印再生成一個int類型的0整個表達(dá)式結(jié)果就是0于是可以放進(jìn)std::initializer_listint。...把參數(shù)包展開成一組用逗號分隔的表達(dá)式。這個寫法不需要遞歸模板實例化層級少編譯效率更好缺點是讀起來比較勸退。第三種方式是在C17里最簡單直接的——折疊表達(dá)式下面單獨說。4.2 折疊表達(dá)式C17之后的簡潔寫法折疊表達(dá)式讓變參模板的可讀性提升了一大截。它的語法看一眼就明白一半template typename... Args void print_all_fold(const Args... args) { (std::cout ... args) std::endl; }這個表達(dá)式(std::cout ... args)是左折疊等價于把args從左到右依次拼到std::cout上。對于打印這種沒有累積結(jié)果的場景更常用的是逗號折疊template typename... Args void print_all_fold2(const Args... args) { ((std::cout args ), ...); std::cout std::endl; }逗號折疊會把每個參數(shù)依次打印出來中間的逗號不是打印內(nèi)容而是折疊操作符。我當(dāng)時第一次看到(...)這個寫法有點懵但只要記住一點折疊表達(dá)式是對參數(shù)包做一次編譯期的二元歸約一元右折(args op ...)從最后一個參數(shù)開始一元左折(... op args)從第一個參數(shù)開始。折疊表達(dá)式特別適合做求和、拼接、邏輯與這類累積操作。比如template typename... Args auto sum_all(Args... args) { return (args ... 0); // 二元折疊初始值0避免空包報錯 }注意空參數(shù)包時沒有初始值的折疊表達(dá)式是非法的所以求和時最好加上一個初始值。4.3 變參模板在工廠函數(shù)與完美轉(zhuǎn)發(fā)中的應(yīng)用變參模板最常見的一個實際場景是寫工廠函數(shù)。標(biāo)準(zhǔn)庫里的std::make_shared、std::make_unique本質(zhì)就是變參模板加完美轉(zhuǎn)發(fā)。一個簡化版本可以這樣寫template typename T, typename... Args std::shared_ptrT my_make_shared(Args... args) { return std::shared_ptrT(new T(std::forwardArgs(args)...)); }這里的關(guān)鍵是Args... args和std::forwardArgs(args)...。Args不是普通的右值引用而是轉(zhuǎn)發(fā)引用也叫萬能引用它可以根據(jù)實參自動推導(dǎo)成左值引用或右值引用。std::forward的作用是保留參數(shù)原有的值類別如果調(diào)用方傳進(jìn)來的是一個左值就按左值轉(zhuǎn)發(fā)如果是右值就按右值轉(zhuǎn)發(fā)。這樣一來構(gòu)造函數(shù)里不會因為參數(shù)中途丟失“移動語義”或“拷貝語義”而引發(fā)不必要的拷貝。我第一次接觸這個寫法時總是想不通為什么要這么繞。后來我明白了在模板函數(shù)內(nèi)部具名的參數(shù)都是左值哪怕實參原本是右值。如果不加std::forward原本可以移動構(gòu)造的對象被迫拷貝構(gòu)造性能白白損失。這個細(xì)節(jié)在寫高性能容器、事件分發(fā)系統(tǒng)時非常關(guān)鍵。5. 模板元編程與類型萃取把運行期的判斷搬到編譯期5.1std::is_same和std::enable_if的搭配模板真正強大的地方不只在于生成代碼還在于可以在編譯期“根據(jù)類型做判斷”。C11標(biāo)準(zhǔn)庫提供了大量類型萃取工具比如std::is_sameT, U專門用來判斷兩個類型是否一致。但如果你直接這么寫多半會掉坑里template typename T void process(const T value) { if (std::is_sameT, int::value) { // 假設(shè)這里調(diào)用了value.someIntMethod() } else { // 假設(shè)這里調(diào)用了value.someStringMethod() } }問題在于模板實例化時if的兩個分支都會被編譯無論T是int還是std::string兩個分支里那些“不存在的方法”都會導(dǎo)致編譯失敗。運行期判斷無法阻止編譯期錯誤。正確做法是讓不滿足條件的分支從編譯過程里直接消失。std::enable_if就是為此設(shè)計的template typename T typename std::enable_ifstd::is_sameT, int::value, void::type process(const T value) { std::cout 處理int std::endl; } template typename T typename std::enable_if!std::is_sameT, int::value, void::type process(const T value) { std::cout 處理其他類型 std::endl; }std::enable_if條件, 類型::type只在條件為真時才存在條件為假時整個函數(shù)聲明就是非法的編譯器直接丟棄這個重載。這相當(dāng)于在編譯期做了一次“替換失敗不是錯誤”SFINAE的篩選。不過說實話這種寫法讀起來很拗口。C17之后有了if constexpr相同場景簡單得多template typename T void process(const T value) { if constexpr (std::is_sameT, int::value) { // 只在T是int時編譯 } else { // 只在T不是int時編譯 } }if constexpr的真正意思是“在編譯期選擇一個分支另一個分支不實例化”。這比enable_if直觀太多所以我的經(jīng)驗是新項目盡量用if constexprenable_if更多用于需要參與重載決議的場合。5.2 一個編譯期階乘模板理解遞歸實例化的邊界模板元編程最經(jīng)典的教學(xué)示例是在編譯期計算階乘。用模板遞歸來實現(xiàn)template int N struct Factorial { static const int value N * FactorialN - 1::value; }; // 偏特化/特化提供遞歸終止條件 template struct Factorial0 { static const int value 1; }; // 用法 static_assert(Factorial5::value 120, 5! should be 120);這段代碼展示了一個元編程的核心模式用模板參數(shù)驅(qū)動遞歸用特化提供終止條件。Factorial5實例化時需要Factorial4Factorial4又需要Factorial3……直到Factorial0這個特化版本提供了出口。我在學(xué)習(xí)時問過自己既然C11就有constexpr函數(shù)了為什么還要研究模板遞歸因為兩者側(cè)重點不同。constexpr函數(shù)是可以被編譯期計算的普通函數(shù)寫法更自然適用范圍更廣但模板遞歸可以在“編譯期產(chǎn)生類型”比如根據(jù)整數(shù)常量生成不同的類型結(jié)構(gòu)這是constexpr函數(shù)做不到的?，F(xiàn)代C實踐中復(fù)雜元編程確實越來越少用“階乘”這種把戲但理解遞歸實例化對弄明白模板是怎么一層層展開出錯誤信息非常有幫助。5.3 元編程的局限編譯時間、可讀性與維護(hù)成本我見過有些開發(fā)者學(xué)會模板元編程后恨不得把所有邏輯塞進(jìn)編譯期結(jié)果項目編譯時間從十幾秒暴漲到幾分鐘。元編程是有代價的每一層模板實例化編譯器都要做一次“類型替換 模式匹配 代碼生成”復(fù)雜元程序甚至?xí)嵗汕先f個模板錯誤信息動輒幾百行。更麻煩的是可維護(hù)性。元編程代碼常?！胺慈祟悺睕]有正常的循環(huán)和變量只有遞歸和常量調(diào)試器里幾乎看不到運行時的中間值加了static_assert可能還好一旦缺少診斷信息后人維護(hù)時只能靠猜。我的經(jīng)驗法則很簡單能用constexpr函數(shù)算出來的就別用模板元編程能用運行期算的也別硬搬進(jìn)編譯期。模板元編程最適合處理的是“類型的選擇與轉(zhuǎn)換”比如判斷某類型是否滿足某接口、在不同類型之間做編譯期分發(fā)。至于業(yè)務(wù)計算交給constexpr函數(shù)和普通函數(shù)就好別為了炫技把整個項目拖入編譯地獄。6. C20 Concepts讓模板報錯從“天書”變成人話6.1 定義一個自己的概念直到C20之前模板的約束只能靠enable_if這種“負(fù)向篩選”。問題是當(dāng)約束不滿足時編譯器給出的錯誤信息往往是一大串“模板參數(shù)推導(dǎo)失敗候選模板被忽略”完全沒有告訴你“為什么失敗”。Concepts概念就是為了解決這個問題。概念定義看起來像對類型的一組“體檢要求”。舉個例子我想定義一個“可相加的”概念#include concepts template typename T concept Addable requires(T a, T b) { { a b } - std::convertible_toT; };這里requires后面跟的花括號是個requires表達(dá)式里面可以寫三類要求簡單要求表達(dá)式合法、類型要求typename后面跟的類型存在、復(fù)合要求{表達(dá)式} - 約束既要求表達(dá)式合法又要求結(jié)果滿足某個約束。上面的概念表示T類型要滿足任意兩個T對象相加的結(jié)果必須能轉(zhuǎn)換成T。如果某個類型不支持operator或者加出來的結(jié)果不是T概念檢查就失敗。6.2 把概念用進(jìn)函數(shù)模板的三種寫法定義好概念后約束函數(shù)模板有多種等效寫法我三種都在項目里見過// 寫法一requires子句 template typename T requires AddableT T add(T a, T b) { return a b; } // 寫法二約束模板參數(shù) template Addable T T add(T a, T b) { return a b; } // 寫法三約束auto參數(shù) Addable auto add(Addable auto a, Addable auto b) { return a b; }這三種寫法表達(dá)的是同一個意思選哪種更多是風(fēng)格問題。我個人的偏好是第二種template Addable T它把約束直接寫進(jìn)模板參數(shù)列表讀起來最自然。第一種適合約束條件比較復(fù)雜、需要多行requires表達(dá)式的情況。第三種雖然簡潔但適合用在約束很輕的場景如果概念本身很復(fù)雜會讓函數(shù)聲明顯得擁擠。概念帶來的最大好處是錯誤信息質(zhì)量顯著提升。當(dāng)你用一個不支持的類型去調(diào)用add時編譯器會直接告訴你“約束未滿足因為SomeType不滿足Addable”。雖然還是有一定閱讀門檻但相比之前滿屏的模板參數(shù)替換記錄已經(jīng)像人話了。6.3 概念對重載決議的影響與注意點概念不只是語法糖它還參與重載決議。簡單說更受約束的函數(shù)模板在重載時會勝出。比如template typename T requires std::integralT void test(T) { std::cout 整型版本 std::endl; } template typename T requires std::signed_integralT void test(T) { std::cout 有符號整型版本 std::endl; }如果調(diào)用test(3)兩個模板都能匹配但std::signed_integral比std::integral更嚴(yán)格多了“有符號”的限制編譯器認(rèn)為它的約束更“受約束”所以第二個版本勝出。這個機制叫約束偏序編譯器會自動比較兩個約束的邏輯包含關(guān)系。這里要特別注意一點約束偏序的判斷依賴于約束表達(dá)式本身的結(jié)構(gòu)不一定總能推導(dǎo)出“更嚴(yán)格”。如果兩個概念之間沒有明顯的蘊含關(guān)系調(diào)用時就會報重載歧義。我在寫具有多個約束版本的重載時會刻意給概念起名并保持概念的邏輯層級清晰比如Integral和SignedIntegral這種直接體現(xiàn)包含關(guān)系的命名重載決議和行為都更容易預(yù)測。7. 我踩過的模板編譯錯誤與排查思路7.1 從“no matching function”到真正的調(diào)用棧模板編譯報錯最常見的開頭就是error: no matching function for call to ...緊跟著一屏幕候選模板。剛開始我每次都從第一行開始讀結(jié)果一頭扎進(jìn)幾百行的“模板實例化調(diào)用鏈”里出不來。后來我總結(jié)出一個更高效的排查順序先看調(diào)用點的實參類型是否和函數(shù)模板參數(shù)匹配。比如傳了一個std::string但函數(shù)參數(shù)是const T這通常沒問題但如果實參是int*模板參數(shù)又是T推導(dǎo)結(jié)果就是int*后續(xù)函數(shù)體里若把它當(dāng)成整數(shù)用就會報錯。所以先確認(rèn)推導(dǎo)出來的T是什么再往函數(shù)體里看。其次檢查返回值類型相關(guān)表達(dá)式。很多“no matching function”并不是調(diào)用參數(shù)不匹配而是返回值類型所在的enable_if條件不滿足整個候選模板被SFINAE規(guī)則丟棄。最后才去看輸出列表末尾那幾行“實例化自”位置那里通常指向你業(yè)務(wù)源碼中真正出錯的那一行。編譯器的調(diào)用鏈?zhǔn)菑哪０宥x開始展開的最底部的層次往往才是你的業(yè)務(wù)調(diào)用點從下往上讀會更高效。7.2 模板定義必須可見鏈接期錯誤的定位還有一類錯誤不在編譯期爆發(fā)而是藏在鏈接期。典型報錯是undefined reference to void my_maxint(const int, const int)這個報錯信息里甚至有模板參數(shù)int但很多人第一眼看不出它和模板有什么關(guān)系。原因就是前面說過的模板的定義放在了.cpp里調(diào)用方頭文件里只有聲明實例化被迫中斷最后鏈接器發(fā)現(xiàn)找不到對應(yīng)符號。遇到這種報錯排查路徑是先去檢查該模板定義所在文件是否被包含在調(diào)用方的編譯單元里再確認(rèn)是否有人在.cpp里做了顯式實例化但拼錯了類型。另一個容易忽略的情況是類模板的靜態(tài)成員定義忘了寫這也會在鏈接期出現(xiàn)類似“undefined reference toBoxint::count”的報錯解決方式是回到類外補上模板靜態(tài)成員的定義。7.3 用靜態(tài)斷言和“類型打印”工具輔助診斷排查模板類型推導(dǎo)問題時我特別依賴一個“手工類型打印”的技巧。核心思路是寫一個故意不定義的模板類讓編譯器在報錯時把類型“帶”出來template typename... struct TypePrinter; // 故意不定義 template typename T void debug_type(T) { // 觸發(fā)編譯錯誤報錯信息中會顯示T的類型 static_assert(sizeof(TypePrinterT) 0, 查看T的類型); }只要某個地方調(diào)用了debug_type(expr)編譯器就會在static_assert那里報錯錯誤信息里會顯示TypePrinterint或者TypePrinterconst char ()[6]這類類型全名。這種手段在排查引用、const、數(shù)組退化的推導(dǎo)問題時比任何調(diào)試器都好用。另一個常用工具是static_assert搭配類型萃取static_assert(std::is_samedecltype(x), int::value, 這里推導(dǎo)出來的類型不是int);一旦條件不滿足編譯器會把你寫的提示信息打印出來。我現(xiàn)在的習(xí)慣是在寫復(fù)雜的模板函數(shù)時先在關(guān)鍵推導(dǎo)點放幾個臨時的static_assert確定類型無誤后再刪掉。這比依賴IDE的類型懸停提示更可靠因為編譯器的推導(dǎo)結(jié)果才算是最終事實。最后再分享一點我的個人體會。模板學(xué)習(xí)切忌只看語法一定要親手編譯看報錯修報錯。我建議初學(xué)者不要急著上模板元編程先把函數(shù)模板、類模板、特化、變參模板這四塊跑熟再試Concept。模板報錯確實難看但看得多了你會發(fā)現(xiàn)它其實有規(guī)律可循編譯器會把整個實例化調(diào)用鏈展開你只要從最底層的一條開始看。后續(xù)我還會繼續(xù)整理模板相關(guān)的學(xué)習(xí)筆記比如模板參數(shù)推導(dǎo)的完整規(guī)則和約束偏序的細(xì)節(jié)那又是兩個大坑。