學(xué) C 的人幾乎沒有不碰類模板template的。STL 容器、智能指針、標(biāo)準(zhǔn)庫(kù)算法隨便拉一個(gè)出來都是類模板或函數(shù)模板的產(chǎn)物。但我發(fā)現(xiàn)一個(gè)現(xiàn)象很多人能看懂 vector 、unique_ptr 的用法一轉(zhuǎn)身要自己定義一個(gè)類模板就開始手足無措要么把 template 關(guān)鍵字到處亂放要么干脆不知道成員函數(shù)該怎么寫在類外面。這篇文章我想把 C 類模板從語法骨架到工程實(shí)踐捋一遍重點(diǎn)不是背書而是回答“為什么這樣寫”“為什么我自己寫的時(shí)候會(huì)編譯失敗”以及“什么樣的代碼風(fēng)格能讓模板類長(zhǎng)期可維護(hù)”。無論你是剛學(xué)完類和對(duì)象、第一次看到 template 的初學(xué)者還是寫過一陣子模板卻總是被編譯錯(cuò)誤折騰的開發(fā)者都值得花十幾分鐘從頭過一遍。1. 類模板要解決的最原始痛點(diǎn)為類型寫同一份實(shí)現(xiàn)1.1 沒有模板時(shí)代復(fù)制粘貼帶來的是長(zhǎng)期的維護(hù)負(fù)債想象一下你要寫一個(gè)整數(shù)棧、一個(gè)字符串棧、一個(gè)浮點(diǎn)數(shù)棧。不用模板最直接的做法是復(fù)制三份類改成不同的類型名。類體可能七八十行復(fù)制三份之后看起來也還好對(duì)吧可問題出在改需求的時(shí)候。比如某一天你想給棧加一個(gè)clear()方法或者想把底層存儲(chǔ)從std::vector換掉你就得同步修改三份代碼少改一份某條業(yè)務(wù)分支就會(huì)在運(yùn)行時(shí)崩潰或者行為不一致。再往后添新類型又得復(fù)制第四份、第五份。這就是典型的“復(fù)制粘貼式開發(fā)”的長(zhǎng)期維護(hù)負(fù)債。短時(shí)間內(nèi)爽后續(xù)每次改動(dòng)都在還債。類模板的思路本質(zhì)上很樸素既然這三份類的差別只在于元素類型那我把“類型”這個(gè)詞挖掉留一個(gè)占位符出來。寫一次邏輯讓編譯器在遇到Stackint、Stackstd::string、Stackdouble的時(shí)候分別按你說的類型再去生成對(duì)應(yīng)版本。這個(gè)概念就是“用同一份代碼模板描述一類對(duì)象”也就是類模板的核心價(jià)值。1.2 類模板的思路把“類型”本身變成參數(shù)普通函數(shù)的參數(shù)是變量傳入的是值。類模板的參數(shù)是類型或者稍后會(huì)提到的編譯期常量。你可以把模板理解成給編譯器的一張圖紙templatetypename T class Stack { // 凡是元素類型都用 T 占位 };當(dāng)你寫下Stackint的時(shí)候編譯器拿到這張圖紙把里面所有T替換成int生成一套真正可以實(shí)例化的類。當(dāng)你寫下StackMyUser的時(shí)候再替換一次生成另一套獨(dú)立的類。這跟 C 語言里宏展開的思想有點(diǎn)像但區(qū)別在于模板有嚴(yán)格的語法和類型檢查不是無腦文本替換。關(guān)鍵詞typename和class在這里可以互換老代碼里更常見寫class新代碼大家逐漸習(xí)慣用typename含義完全一致。至于參數(shù)名叫T也不是強(qiáng)制規(guī)定只是慣例你叫ElemType、ValueType都行只要在模板體里保持一致。1.3 順帶澄清類模板和模板類不是同一個(gè)名詞初學(xué)者問“類模板和模板類有什么區(qū)別”的頻率非常高。簡(jiǎn)單說類模板是那個(gè)帶templatetypename T的類定義本身它是一種“圖紙”模板類指的是“已經(jīng)指定了具體類型參數(shù)的類”比如Stackint此時(shí)可以說是一個(gè)模板類實(shí)例。這個(gè)區(qū)分在口語里經(jīng)常混用但寫文章、做設(shè)計(jì)時(shí)搞清楚有助于溝通。真正重要的是類模板本身不是一個(gè)可用的類型你沒法聲明Stack s;必須給出類型參數(shù)得到實(shí)際類型后才能創(chuàng)建對(duì)象。2. 一步步寫一個(gè) Stack 從定義到實(shí)例化的完整骨架2.1 類內(nèi)實(shí)現(xiàn)版本最直觀的第一版先看一段完整的StackT類內(nèi)實(shí)現(xiàn)。作為示例我直接依賴std::vectorT做底層存儲(chǔ)這樣聚焦在模板語法上而不是數(shù)據(jù)結(jié)構(gòu)細(xì)節(jié)。#include vector #include stdexcept templatetypename T class Stack { public: void push(const T value) { data_.push_back(value); } void pop() { if (data_.empty()) { throw std::out_of_range(Stack::pop(): empty stack); } data_.pop_back(); } T top() { if (data_.empty()) { throw std::out_of_range(Stack::top(): empty stack); } return data_.back(); } bool empty() const { return data_.empty(); } size_t size() const { return data_.size(); } private: std::vectorT data_; };注意std::vectorT里的T。當(dāng)T是int時(shí)成員變量就是std::vectorint當(dāng)T是自定義類型Product時(shí)成員變量就是std::vectorProduct。模板參數(shù)一旦傳入編譯器會(huì)沿整個(gè)類定義把所有出現(xiàn)T的地方都替換掉包括普通函數(shù)參數(shù)、返回值、局部變量和成員變量聲明。使用方式很直接Stackint intStack; intStack.push(1); Stackstd::string strStack; strStack.push(hello);這里有個(gè)容易誤解的地方Stackint和Stackstd::string是兩個(gè)完全無關(guān)的類型它們之間沒有繼承、也沒有隱式轉(zhuǎn)換關(guān)系。你寫一個(gè)普通函數(shù)void foo(Stackint)傳Stackstd::string進(jìn)去編譯器會(huì)直接報(bào)類型不匹配因?yàn)榫幾g器確實(shí)生成了兩套獨(dú)立的類。2.2 成員函數(shù)在類外定義時(shí)的重復(fù)寫法實(shí)際項(xiàng)目里為了讓類的接口更清晰、降低編譯期依賴經(jīng)常把聲明和定義分開。普通類在類外定義成員函數(shù)時(shí)只需要寫ClassName::functionName。模板類就不一樣每個(gè)類外定義的成員函數(shù)都必須重新帶上templatetypename T同時(shí)要寫StackT::。templatetypename T void StackT::push(const T value) { data_.push_back(value); } templatetypename T void StackT::pop() { if (data_.empty()) { throw std::out_of_range(Stack::pop(): empty stack); } data_.pop_back(); } templatetypename T T StackT::top() { if (data_.empty()) { throw std::out_of_range(Stack::top(): empty stack); } return data_.back(); }在頭文件里這樣寫的時(shí)候templatetypename T這行聲明必須緊跟對(duì)應(yīng)定義。有人會(huì)把templatetypename T寫漏或者寫成了templatetypename T但函數(shù)名卻寫Stack而不是StackT編譯器就會(huì)報(bào)類似“缺少模板實(shí)參”的錯(cuò)。還有一個(gè)容易忽略的點(diǎn)普通類可以一個(gè)::走天下模板類在嵌套作用域里更要小心比如構(gòu)造函數(shù)寫在類外templatetypename T StackT::Stack() default;在 C11 之后即便想 default不在類內(nèi)寫也要把這個(gè)聲明放在類里類外才補(bǔ)定義。如果干脆不寫任何構(gòu)造編譯器生成默認(rèn)構(gòu)造你也不需要額外操心。2.3 交給編譯器的“實(shí)例化”到底發(fā)生在什么時(shí)候很多初學(xué)者背下了模板語法卻搞不明白模板代碼什么時(shí)候被真正編譯。實(shí)際上模板定義里的語法錯(cuò)誤在編譯器看到templatetypename T class Stack {...}時(shí)就會(huì)檢查一部分但和類型相關(guān)的邏輯錯(cuò)誤往往要等到你寫出Stackint這樣的實(shí)例化表達(dá)式之后編譯器才會(huì)把T替換成int再全量檢查一遍成員函數(shù)體。這就是為什么有人寫了一個(gè)模板類從來沒使用過它編譯通過了一旦真用起來報(bào)了一堆錯(cuò)。真實(shí)原因是你沒有實(shí)例化它編譯器沒必要去檢查“把T替換為某個(gè)類型后函數(shù)體里的所有操作是否合法”。只要T是未知的很多操作沒法提前判定。這個(gè)機(jī)制既方便又危險(xiǎn)方便在于模板代碼可以寫得很通用危險(xiǎn)在于如果你只用某一套類型實(shí)例化另一條函數(shù)分支可能從來沒被檢查過等線上某個(gè)怪異的類型觸發(fā)時(shí)才炸。2.4 構(gòu)造函數(shù)的模板參數(shù)推導(dǎo)C17 帶來的改變?cè)?C17 之前寫Stack這類模板你必須顯式給出類型參數(shù)Stackint s;哪怕構(gòu)造函數(shù)里已經(jīng)傳了int進(jìn)去編譯器也不會(huì)替你猜。C17 引入了類模板實(shí)參推導(dǎo)CTAD一部分場(chǎng)景下可以直接簡(jiǎn)寫templatetypename T class AutoStack { public: AutoStack(T seed) : data_{seed} {} private: std::vectorT data_; }; AutoStack s{42}; // C17 推導(dǎo)出 AutoStackint這對(duì)減少冗余非常有幫助但推導(dǎo)也不是永遠(yuǎn)符合直覺。構(gòu)造函數(shù)有多個(gè)參數(shù)、參數(shù)類型不完全一致、或者有默認(rèn)構(gòu)造時(shí)推導(dǎo)規(guī)則會(huì)變復(fù)雜。后面第 6 部分我再單獨(dú)展開。3. 非類型參數(shù)、默認(rèn)參數(shù)和特化類模板不止能傳類型3.1 非類型模板參數(shù)把一個(gè)編譯期常量傳給類類型可以作為模板參數(shù)整數(shù)、枚舉、指針等編譯期常量也可以。最常見的就是std::arrayT, N第二個(gè)參數(shù)N是std::size_t類型的非類型模板參數(shù)。templatetypename T, size_t Capacity class FixedBuffer { public: T operator[](size_t index) { return data_[index]; } size_t capacity() const { return Capacity; } private: T data_[Capacity]; }; FixedBufferint, 256 buf;寫T data_[Capacity]意味著Capacity必須是一個(gè)編譯期已知的常量表達(dá)式不能是變量也不能是函數(shù)返回的運(yùn)行時(shí)值。聯(lián)系到上一節(jié)的實(shí)例化機(jī)制FixedBufferint, 256和FixedBufferint, 512也是兩個(gè)不同的類型因?yàn)樯傻膬?nèi)部數(shù)組大小不同。非類型模板參數(shù)的類型限制在不同標(biāo)準(zhǔn)版本里有變化。早期只允許整型、枚舉、指針和左值引用到了 C20結(jié)構(gòu)體類型的字面量也可以作為非類型模板參數(shù)。實(shí)際工程里最常見的仍然是非負(fù)整數(shù)和指針別在模板參數(shù)列表里塞浮點(diǎn)數(shù)double——浮點(diǎn)數(shù)在編譯期比較多少存在精度和等價(jià)性問題標(biāo)準(zhǔn)過去明確禁止現(xiàn)在某些場(chǎng)景仍容易踩坑。3.2 默認(rèn)模板參數(shù)什么時(shí)候能用、什么時(shí)候不能用類模板和函數(shù)類似也可以給模板參數(shù)一個(gè)默認(rèn)值templatetypename T, typename Container std::vectorT class Stack { public: void push(const T value) { data_.push_back(value); } private: Container data_; }; Stackint s1; // 相當(dāng)于 Stackint, std::vectorint Stackint, std::dequeint s2;給第二個(gè)模板參數(shù)默認(rèn)值之后就能在不指定Container的情況下直接使用Stackint。需要注意默認(rèn)值的展開是“參數(shù)相關(guān)”的std::vectorT里的T是第一個(gè)模板參數(shù)C 的默認(rèn)模板參數(shù)允許引用前面的模板參數(shù)這是合法的而且非常實(shí)用。不過你不能讓一個(gè)帶默認(rèn)值的參數(shù)出現(xiàn)在不帶默認(rèn)值的參數(shù)前面除非編譯器能推斷出該參數(shù)的實(shí)參。規(guī)則和函數(shù)默認(rèn)參數(shù)很像一旦某個(gè)參數(shù)開始使用默認(rèn)值后面所有參數(shù)也必須提供默認(rèn)值。類模板構(gòu)造時(shí)如果想顯式指定Container但讓第一個(gè)參數(shù)用默認(rèn)值那是做不到的因?yàn)槟０鍖?shí)參按位置匹配沒辦法“跳過”。3.3 全特化與偏特化當(dāng)同一套代碼覆蓋不了特殊情況類模板的通用實(shí)現(xiàn)是針對(duì)絕大多數(shù)類型的但某些具體類型可能需要完全不同的處理。比如你要寫一個(gè)通用的類型信息打印工具TypeDescriberT對(duì)普通類型返回名字對(duì)int和std::string單獨(dú)給出更具體的信息。這時(shí)就可以做全特化。#include string templatetypename T struct TypeDescriber { static const char* name() { return unknown; } }; template struct TypeDescriberint { static const char* name() { return int; } }; template struct TypeDescriberstd::string { static const char* name() { return std::string; } };寫法是先寫template表示這是一個(gè)對(duì)某個(gè)具體類型的全特化后面跟struct TypeDescriberint。注意template后面是空的尖括號(hào)不是templatetypename T。當(dāng)你調(diào)用TypeDescriberdouble::name()時(shí)走通用版本調(diào)用TypeDescriberint::name()時(shí)走特化版本。偏特化則更進(jìn)一步你并不把所有模板參數(shù)都確定下來而是對(duì)某一類形態(tài)做定制。比如“所有指針類型”是一個(gè)形態(tài)“所有 const 限定類型”是另一個(gè)形態(tài)templatetypename T struct TypeDescriberT* { static const char* name() { return pointer; } }; templatetypename T struct TypeDescriberconst T { static const char* name() { return const value; } };偏特化最常見的形態(tài)包括指針類型、引用類型、std::arrayT, N這種容器類型。本質(zhì)上編譯器在模板匹配時(shí)會(huì)優(yōu)先選擇更特化的版本。它能支持非常復(fù)雜的模式匹配比如templatetypename T, typename U struct X;可以偏特化出templatetypename U struct Xint, U這意味著“當(dāng)?shù)谝粋€(gè)參數(shù)是int時(shí)就用這套特別的實(shí)現(xiàn)”。掌握這一招寫類型萃取和編譯期分發(fā)會(huì)輕松很多。3.4 特化誤用警告不要試圖偏特化函數(shù)模板這里想特別提醒一句類模板可以偏特化函數(shù)模板不能偏特化。很多人學(xué)到類模板偏特化后會(huì)順手在函數(shù)模板上試// 不要這樣寫編譯器會(huì)報(bào)錯(cuò)或者行為不符合預(yù)期 templatetypename T void foo(T value) {} templatetypename T void fooT*(T* value) {} // 函數(shù)模板不能偏特化函數(shù)模板如果要對(duì)指針做特殊處理更常規(guī)的做法是使用函數(shù)重載或者通過 C20 的requires約束實(shí)現(xiàn)。你不必非要“修正”這一限制。理解了類模板偏特化和全特化的區(qū)別工程中就夠用了。4. 成員函數(shù)、友元和繼承類模板組合玩法中的容易出事點(diǎn)4.1 依賴類型必須寫 typename寫類模板時(shí)成員變量或者函數(shù)體里經(jīng)常會(huì)用到“依賴類型”也就是依賴于模板參數(shù)的類型。比如你希望T內(nèi)部包含一個(gè)iterator類型templatetypename T class CollectionHelper { public: void iterate() { // 這里 T::iterator 是依賴類型 typename T::iterator it container_.begin(); while (it ! container_.end()) { it; } } private: T container_; };T::iterator為什么必須加typename因?yàn)樵诰幾g器眼里T是未知的T::iterator可能是一個(gè)類型也可能是T里的一個(gè)靜態(tài)變量名。C 語法規(guī)定在模板中默認(rèn)把這種限定名當(dāng)作值處理除非你顯式用typename告訴它“這是一個(gè)類型”。不加typename時(shí)編譯錯(cuò)誤往往很繞比如“需要類型說明符”或“缺少;”。這個(gè)錯(cuò)誤在類模板里非常高頻我在很多代碼評(píng)審里都見過。同樣的規(guī)則還體現(xiàn)在類型別名上templatetypename T using IteratorType typename T::iterator;4.2 友元函數(shù)在類模板內(nèi)部的兩種寫法普通類的友元很好理解類模板里的友元稍微復(fù)雜。最常見、也最不容易出錯(cuò)的是“在類內(nèi)部直接定義友元函數(shù)”此時(shí)友元函數(shù)和當(dāng)前模板實(shí)例綁在一起templatetypename T class Number { public: Number(T value) : value_(value) {} friend Number operator(const Number lhs, const Number rhs) { return Number(lhs.value_ rhs.value_); } private: T value_; };這樣每次實(shí)例化Numberint時(shí)會(huì)同時(shí)生成一個(gè)對(duì)應(yīng)的operator(const Numberint, const Numberint)函數(shù)。它只接受與當(dāng)前實(shí)例化完全匹配的類型避免了跨類型的隱式轉(zhuǎn)換問題。很多運(yùn)算符重載的模板實(shí)現(xiàn)都用這種內(nèi)聯(lián)友元寫法。如果你想在類外定義友元函數(shù)需要先聲明模板函數(shù)再在友元聲明處用模板參數(shù)來“特指”寫法比較繁瑣而且很容易出現(xiàn)“友元函數(shù)模板匹配不上”的謎之錯(cuò)誤。對(duì)于大多數(shù)業(yè)務(wù)代碼我更推薦優(yōu)先用成員函數(shù)或者內(nèi)聯(lián)友元只有在需要支持形如T U這樣兩個(gè)不同類型同時(shí)參與運(yùn)算時(shí)才考慮外部模板函數(shù)配合友元。4.3 繼承類模板注意依賴基類名字的坑類模板也可以繼承其它類模板。這個(gè)場(chǎng)景在實(shí)現(xiàn)“自定義容器適配器”或者“策略模式”時(shí)經(jīng)常遇到。比如基類是一個(gè)帶有某個(gè)成員函數(shù)的模板templatetypename T class Base { public: void baseMethod() { // ... } }; templatetypename T class Derived : public BaseT { public: void derivedMethod() { baseMethod(); // 這里可能編譯失敗 } };在模板派生類里直接寫baseMethod()可能報(bào)錯(cuò)因?yàn)榫幾g器在解析非依賴名字時(shí)不會(huì)去依賴基類BaseT中查找——在模板定義階段它對(duì)BaseT一無所知不能確定baseMethod是否存在。解決辦法是用this-讓它變成依賴表達(dá)式或者顯式寫B(tài)aseT::baseMethod()templatetypename T class Derived : public BaseT { public: void derivedMethod() { this-baseMethod(); BaseT::baseMethod(); } };這個(gè)看起來像“多此一舉”的this-實(shí)際上是模板兩階段查找機(jī)制的直接后果。只有理解了這個(gè)規(guī)則遇到這類報(bào)錯(cuò)時(shí)才會(huì)想到去加this-而不是懷疑編譯器壞了。5. 模板代碼為什么必須放頭文件編譯模型與鏈接錯(cuò)誤5.1 編譯器要看到完整的模板定義才能“按實(shí)參生成代碼”普通類的做法是頭文件放聲明源文件放實(shí)現(xiàn)調(diào)用方編譯時(shí)只需看到類聲明。但類模板不能這么干。原因很簡(jiǎn)單編譯器在Stackint s;這一行需要知道Stackint的完整定義包括成員變量大小、成員函數(shù)函數(shù)體才能生成代碼。如果頭文件里只有templatetypename T class Stack;這行聲明沒有實(shí)現(xiàn)實(shí)例化時(shí)就會(huì)報(bào)“未定義類型”或鏈接階段提示缺少函數(shù)實(shí)現(xiàn)。一種常見但很糟糕的做法是試圖把模板實(shí)現(xiàn)寫在.cpp里然后讓另一個(gè).cppinclude 它。這么做經(jīng)常導(dǎo)致多份定義或者鏈接錯(cuò)誤。正確做法是把模板定義完全放在頭文件里或者至少讓實(shí)現(xiàn)對(duì)使用方可見。這不是 C 的缺陷而是模板實(shí)例化模型決定的——它不像 Java 泛型那樣在運(yùn)行時(shí)抹除類型而是在編譯期替使用方把具體類型生成出來。5.2 extern template 與顯式實(shí)例化大型工程的務(wù)實(shí)手段當(dāng)同一個(gè)模板被幾十個(gè)源文件使用同一組參數(shù)實(shí)例化時(shí)每編譯一個(gè).cpp編譯器都生成一份相同的實(shí)例化代碼鏈接器再合并去重。編譯時(shí)間會(huì)變得很難看。C11 提供了extern template幫助緩解這個(gè)問題?；酒鸩绞窃谀骋粋€(gè).cpp里顯式實(shí)例化你需要的類型// stack_inst.cpp #include Stack.h template class Stackint; template class Stackdouble;然后在頭文件里聲明這些實(shí)例在其它翻譯單元已經(jīng)存在// Stack.h extern template class Stackint; extern template class Stackdouble;這樣其它.cpp看到Stackint時(shí)會(huì)相信“它的已經(jīng)完全實(shí)例化編譯這一份時(shí)別再生成第 N 遍”從而減少編譯時(shí)間。代價(jià)是你必須提前手動(dòng)列出所有用到的類型組合這對(duì)類型不定、用戶會(huì)自由實(shí)例化的泛型組件來說并不現(xiàn)實(shí)。所以extern template通常用于庫(kù)內(nèi)部已知的熱點(diǎn)實(shí)例比如標(biāo)準(zhǔn)庫(kù)就大量用于std::string、std::vector...的顯式實(shí)例化。普通業(yè)務(wù)項(xiàng)目不必一開始就逼自己用等編譯時(shí)間真的大到影響開發(fā)效率時(shí)再針對(duì)性優(yōu)化。5.3 兩階段查找模板代碼亂序帶來的常見編譯問題模板的名字查找分為兩個(gè)階段。第一階段是解析模板定義本身時(shí)查找不依賴模板參數(shù)的名字第二階段是在實(shí)例化時(shí)查找依賴模板參數(shù)的名字。這正是上一節(jié)派生類調(diào)用基類成員需要this-的深層原因。舉一個(gè)更直白的例子同一段模板代碼放在被調(diào)用函數(shù)之前或之后結(jié)果可能不同void helper() { // ... } templatetypename T struct Test { void call() { helper(); // 第一階段就能找到非依賴名字 helper T::action(); // 第二階段實(shí)例化時(shí)查找 } };如果helper在模板定義處之后才聲明第一階段就找不到即使你實(shí)例化模板時(shí)helper已經(jīng)存在也不行。非依賴名字必須在模板定義處可見。理解了這一點(diǎn)排查“為什么模板內(nèi)調(diào)用的全局函數(shù)找不到”這類問題就知道該往哪個(gè)方向查了。6. 現(xiàn)代 C 給類模板帶來的新變化CTAD、可變參數(shù)模板與工程習(xí)慣6.1 C17 類模板實(shí)參推導(dǎo)簡(jiǎn)化了日常使用前面提過 C17 的 CTADClass Template Argument Deduction。它最實(shí)用的場(chǎng)景是配合構(gòu)造函數(shù)推導(dǎo)類型參數(shù)減少手寫冗余聲明。比如templatetypename T struct Point { Point(T x, T y) : x_(x), y_(y) {} T x_; T y_; }; Point p(1.5, 2.5); // 推導(dǎo)出 Pointdouble如果兩個(gè)參數(shù)類型不一致比如Point p(1, 2.5)那么推導(dǎo)會(huì)失敗因?yàn)闆]有唯一確定的T。這時(shí)候編譯器報(bào)錯(cuò)反而能幫我們發(fā)現(xiàn)設(shè)計(jì)問題到底是該傳兩個(gè)int還是應(yīng)該把其中一個(gè)隱式轉(zhuǎn)換模板推導(dǎo)的理想是盡量自動(dòng)但不會(huì)替你決定潛在歧義。6.2 通過 deduction guide 糾正推導(dǎo)結(jié)果CTAD 雖然方便但推導(dǎo)結(jié)果偶爾不理想。典型場(chǎng)景是你希望模板參數(shù)類型是“去掉引用和 const 后的類型”或者想對(duì)字符串字面量做特殊處理。C17 允許自定義推導(dǎo)指引deduction guide直接告訴編譯器“遇到這種構(gòu)造方式時(shí)推導(dǎo)成什么類型”templatetypename T struct MyString { MyString(const T value) : value_(value) {} T value_; }; // 當(dāng)傳入 const char* 時(shí)不要推導(dǎo)成 const char*而希望保存為 std::string MyString(const char*) - MyStringstd::string;這樣寫MyString s hello;時(shí)推導(dǎo)結(jié)果不是MyStringconst char*而是MyStringstd::string。這個(gè)技巧在寫各種包裝類、適配器類時(shí)很常用。需要區(qū)分推導(dǎo)指引只影響推導(dǎo)并不會(huì)改變真實(shí)的構(gòu)造函數(shù)行為。6.3 可變參數(shù)類模板C11 引入的模板參數(shù)包讓類模板也能接收數(shù)量不定的類型參數(shù)。最典型的例子就是std::tupletemplatetypename... Ts struct MyTuple { MyTuple(Ts... args) : values_(args...) {} std::tupleTs... values_; }; MyTuple t(1, 2.5, std::string(hello));這里的Ts...是一個(gè)類型參數(shù)包展開后等價(jià)于把多個(gè)類型塞進(jìn)模板參數(shù)列表。你需要區(qū)分兩個(gè)展開位置類型展開和表達(dá)式展開。std::tupleTs...是類型展開MyTuple(Ts... args)是把參數(shù)包展開成構(gòu)造函數(shù)參數(shù)args...是表達(dá)式展開。可變參數(shù)模板很容易把代碼風(fēng)格推向“高級(jí) but 難讀”的極端。我用下來的體會(huì)是盡量把參數(shù)包展開集中在一兩個(gè)內(nèi)部工具函數(shù)里不要讓展開邏輯散布整個(gè)類外部。std::apply、折疊表達(dá)式這些機(jī)制也能顯著簡(jiǎn)化展開代碼C17 以后寫起來舒服多了。6.4 我寫類模板時(shí)堅(jiān)持的幾個(gè)習(xí)慣最后分享幾條實(shí)際經(jīng)驗(yàn)都是踩過坑才總結(jié)出來的。第一類模板的對(duì)外接口盡量保持小。模板代碼一旦編譯錯(cuò)誤報(bào)錯(cuò)信息動(dòng)輒幾百行接口越復(fù)雜理解成本越高。能拆成普通函數(shù)就別把所有邏輯都塞進(jìn)模板類里保證只有真正需要類型參數(shù)的地方才用模板。第二所有依賴類型都顯式寫typename。這會(huì)讓代碼啰嗦一點(diǎn)但極大降低編譯期歧義。代碼是寫給其他人讀的typename T::iterator一眼就能看出“這是類型別名”不加則要猜半天。第三模板定義按“先聲明、后定義”組織把非模板邏輯部分盡量抽到普通函數(shù)。模板實(shí)現(xiàn)放頭文件不假但頭文件內(nèi)部依然可以分成接口聲明區(qū)、實(shí)現(xiàn)區(qū)。大型項(xiàng)目里還可以考慮把模板實(shí)現(xiàn)拆到_impl.h文件里主頭文件在末尾 include 它至少?gòu)挠^賞性上會(huì)清爽很多。第四別輕易用特化做“性能 hack”。很多人拿到模板第一反應(yīng)是給特定類型做特化來優(yōu)化。特化本身沒問題但每多一個(gè)特化維護(hù)成本就多一層。業(yè)務(wù)沒有實(shí)際性能壓力時(shí)先把通用實(shí)現(xiàn)寫對(duì)再說。真要優(yōu)化用 C20 的 concepts 和requires約束來分派不同實(shí)現(xiàn)代碼語義比滿天飛的template清晰得多。模板是 C 最有表達(dá)力也最考驗(yàn)人的一個(gè)部分。類模板作為模板體系的基石值得每個(gè)人花時(shí)間把實(shí)例化、特化、友元、繼承這些邊界都過一遍。真正掌握它的標(biāo)志不是能背語法而是面對(duì)一條報(bào)錯(cuò)時(shí)能在腦子里快速定位這多半是依賴類型沒寫typename還是模板實(shí)現(xiàn)沒被實(shí)例化到還是名字查找階段就出了問題。有了這個(gè)定位能力模板世界的門檻就基本被跨過了。