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