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