C的“多態(tài)”這兩個字面試里被問的頻率有多高就不用我多說了。但你發(fā)現(xiàn)沒有大多數(shù)人聊多態(tài)翻來覆去就是“虛函數(shù)、繼承、重寫”三板斧再深一層就說不下去了。這東西表面看著簡單實際上底層的機制、內(nèi)存布局、性能代價、設計上的取舍每一層都有不少值得一提的細節(jié)。我這篇文章就打算把C多態(tài)從頭到尾捋一遍從最基礎的“是什么、解決什么問題”開始一路拆到虛函數(shù)表的內(nèi)部原理、實踐中常見的幾個“坑”再到現(xiàn)代C里面對多態(tài)的一些新思路。不管你是剛把語法看完的初學者還是寫了幾年C想補一補基礎的老手這篇文章應該都能給你一點有用的東西。先說清楚一件事我們討論的“多態(tài)”如果你去翻標準文檔嚴格來說“多態(tài)類型”指的是“有虛函數(shù)或繼承自此類類型的類類型”。但在實際的開發(fā)口語里大家說“多態(tài)”十有八九指的是“通過基類指針調(diào)用派生類重寫后的函數(shù)”這個能力。所以下文里提到的“多態(tài)”如果不加特別說明都是指這個運行時行為。咱們按這個口徑來聊。1. 從多態(tài)的種類說起1.1 編譯期多態(tài)和運行期多態(tài)的區(qū)別C里的多態(tài)其實分成兩大類編譯期多態(tài)和運行期多態(tài)。這兩個東西解決問題的思路完全不同也會影響到你的代碼設計。編譯期多態(tài)的核心機制是模板再加上函數(shù)重載、運算符重載。它的特點是調(diào)用哪一份代碼在編譯階段就已經(jīng)確定了編譯器會根據(jù)你實際傳進去的類型生成對應的函數(shù)實體。好處是什么呢性能好因為沒有運行時判斷的開銷而且編譯器可以把類型信息拿到手上做各種內(nèi)聯(lián)優(yōu)化。壞處也很明顯——生成代碼會膨脹編譯時間會變長而且你沒法在運行的時候根據(jù)條件來動態(tài)選擇行為。運行期多態(tài)就是大家最熟悉的“虛函數(shù)版多態(tài)”。它的核心是程序運行的時候通過基類的指針或者引用去調(diào)用一個在派生類里被重寫過的虛函數(shù)。這個調(diào)用不是編譯時確定的而是要等到運行時根據(jù)對象真正的類型去查一個表才能找到具體該調(diào)用哪個函數(shù)。它帶來的是靈活的擴展性你可以在不修改已有代碼的前提下往系統(tǒng)里增加新的行為這就是“開閉原則”里說的那種“對擴展開放對修改關閉”。我經(jīng)常拿一個生活場景來類比這兩者的區(qū)別。編譯期多態(tài)就像是你提前把人約好了第二天直接到點見面什么都不會變。運行期多態(tài)則是你到服務大廳辦事拿號排隊窗口那邊會根據(jù)你的情況安排具體哪一個柜臺來接待你。一個“早就定死了”一個“到時候再說”區(qū)別就在這。很多初學者容易把這兩個搞混以為只要用了模板就是多態(tài)或者以為只有虛函數(shù)才叫多態(tài)。嚴格來說都沒錯但在C工程師之間的日常溝通里當有人問“多態(tài)是怎么實現(xiàn)的”時他基本是在問運行期多態(tài)也就是虛函數(shù)那一套。下面咱們重點展開的也正是這一條線。1.2 重載、重寫、隱藏三件看著像但其實完全不同的事既然聊到了多態(tài)就必須把“重載overload”“重寫override”“隱藏hide”這三個詞徹底掰扯清楚。我見過太多人在簡歷里寫“熟悉C多態(tài)”結(jié)果一問你“重寫和隱藏有什么區(qū)別”立刻卡殼。先說重載。重載是指在同一作用域內(nèi)通常是同一個類內(nèi)部函數(shù)名相同但參數(shù)列表不同——參數(shù)個數(shù)、類型或者順序有一處不同就算。重載與多態(tài)沒有直接關系因為它本質(zhì)上是編譯器根據(jù)實參在編譯期決定調(diào)用哪一個版本。然后說重寫。這是多態(tài)的核心動作。派生類中定義一個與基類虛函數(shù)完全相同的函數(shù)簽名函數(shù)名、參數(shù)列表、返回值并且用override關鍵字明示這個就叫重寫。注意前提基類該函數(shù)必須是virtual的否則就不能叫重寫。最后是隱藏。這個名字很容易讓人誤解。派生類中定義了一個名字相同的函數(shù)但參數(shù)列表和基類的不一樣或者基類的那個函數(shù)不是虛函數(shù)這時候派生類的函數(shù)把基類的同名函數(shù)“遮擋”住了通過派生類對象或指針只能看到派生類的這個版本。這既不是重載因為作用域不同也不是重寫因為不滿足虛函數(shù)重寫的條件而是隱藏。這三個概念在實際開發(fā)中造成最多的困惑就是你以為你寫了重寫編譯器以為你寫了隱藏。這會導致一個非常隱蔽的bug——你通過基類指針調(diào)用函數(shù)結(jié)果根本沒有觸發(fā)多態(tài)反而調(diào)到了基類的版本。我建議所有人在C11之后都用override關鍵字標明重寫意圖編譯器會在你寫錯簽名的時候直接報錯能堵住一大堆隱患。2. 虛函數(shù)表的底層原理多態(tài)是怎么“跑”起來的2.1 虛函數(shù)表與虛函數(shù)指針的結(jié)構運行期多態(tài)能成立靠的是一張“表”——虛函數(shù)表虛表。這張表屬于類而不是某個具體的對象。表里存的是一系列的函數(shù)指針每個虛函數(shù)的地址在編譯時就排好了位置。每個包含虛函數(shù)的類的對象內(nèi)部會多出一個隱藏的指針成員叫虛函數(shù)指針vptr它指向這個類對應的虛表。這樣說可能還是有點抽象。我舉個例子假設你有一個基類Shape里面定義了虛函數(shù)draw()然后有兩個派生類Circle和Square各自重寫了draw()。那么編譯出來的代碼里Shape類有一個虛表表里第0項是Shape::draw()的地址Circle類也有自己的虛表表里第0項是Circle::draw()的地址Square類同理。當你聲明一個Circle對象時這個對象的內(nèi)存開頭會有一個隱藏的指針指向Circle類的虛表。這時候如果你寫Shape* pShape new Circle();然后執(zhí)行pShape-draw()程序?qū)嶋H上做的事是從pShape指向的對象中取出那個隱藏的虛表指針再通過這個指針找到虛表然后跳到虛表第0項指向的函數(shù)。整個過程是動態(tài)的完全取決于pShape所指對象的真實類型。這就是“動態(tài)綁定”的字面意思。2.2 構造函數(shù)和析構函數(shù)里為什么不建議調(diào)用虛函數(shù)既然聊到底層機制就有一個經(jīng)典的坑必須講在構造函數(shù)和析構函數(shù)里調(diào)用虛函數(shù)并不會觸發(fā)多態(tài)。原因是這樣的當你在構造一個派生類對象時構造過程是從基類開始一級一級往下來?；悩嬙旌瘮?shù)執(zhí)行的那個時刻派生類的部分還沒有被初始化對象當時“實際上”還認為自己是個基類對象。所以在這個階段調(diào)用虛函數(shù)即使對象最終是派生類型也只會調(diào)用到基類自己的版本。析構時方向相反是從派生類析構到基類同樣地基類析構函數(shù)執(zhí)行的時候派生類的那部分已經(jīng)被銷毀了虛函數(shù)也調(diào)不到派生類的版本。我舉一個程序員比較容易理解的類比你把派生類的構造函數(shù)想象成是在組裝一臺電腦先裝主板再裝顯卡最后裝系統(tǒng)盤。在只裝好主板的階段你跟這臺電腦說“開娛樂模式”它當然只能響應主板內(nèi)置的基礎功能。不是它不想有娛樂模式是顯卡還沒裝上呢。所以設計層面有一條鐵律不要在構造函數(shù)或析構函數(shù)里直接調(diào)用虛函數(shù)也不要讓構造函數(shù)像工廠一樣去調(diào)用可重寫的虛函數(shù)。如果你確實需要在構造過程中做一些動態(tài)分發(fā)的行為最常見的替代方案是把這些邏輯放到基類的非虛函數(shù)里等對象構造完成后再單獨調(diào)用或者用奇異遞歸模板模式這類編譯期技巧來解決。后文第5節(jié)會聊到一些現(xiàn)代替代思路。2.3 對象內(nèi)存布局與多重繼承下的復雜性單繼承情況的虛表結(jié)構還算清晰每個對象只有一個vptr指向一張表。但一旦進入多重繼承事情就開始變復雜了。多重繼承下一個派生類對象會包含多個虛表指針每個基類子對象對應一個vptr。編譯器會為派生類生成多個虛表每個虛表服務于一個基類的視角。除此之外還有各種鋒利的邊緣情況比如菱形繼承、虛基類、指針調(diào)整this調(diào)整這些都是C里比較容易翻車的領域。舉個典型場景class D : public B, public C然后你用B*和C*分別去指向同一個D對象這兩個指針的值可能并不相同。這是因為編譯器需要對指針做調(diào)整讓它們各自指向?qū)ο髢?nèi)對應基類子對象的起始位置。你平時可能感覺不到這個調(diào)整的存在因為編譯器替你干了但它確實會在底層悄悄發(fā)生。多重繼承里的菱形繼承就更不用說了會引入“虛基類”這個概念。虛基類是為了解決同一個基類被多路徑繼承時產(chǎn)生的重復副本問題但它同時會讓虛函數(shù)表的布局變得相當復雜。對這種復雜度我的個人觀點很明確如果不是在寫非常底層的基礎庫盡量避免使用多重繼承尤其是菱形繼承。用組合或者接口類來代替代碼的可維護性會好得多。3. 虛析構函數(shù)多態(tài)里最容易踩的坑3.1 沒有虛析構會怎么樣在多態(tài)的場景下析構函數(shù)必須聲明為virtual這一點幾乎人人都知道。但“知道必須做”和“明白為什么必須做”是兩回事?？紤]這段代碼class Base { public: ~Base() {} }; class Derived : public Base { public: ~Derived() {} }; Base* ptr new Derived(); delete ptr;Base的析構函數(shù)不是虛函數(shù)那么delete ptr這一步會發(fā)生什么編譯器看到ptr是Base*類型析構函數(shù)的調(diào)用在編譯期就綁定到了Base::~Base()所以只會執(zhí)行基類的析構邏輯派生類里申請的資源、成員變量的清理代碼全部沒有機會執(zhí)行。如果Derived里面有std::vector、std::string等管理著堆內(nèi)存的對象它們的析構就全被跳過了這就是經(jīng)典的內(nèi)存泄漏源頭。有人可能會問我不用delete用智能指針是不是就不怕了還是要怕。std::unique_ptrBase和std::shared_ptrBase拿一個Derived*去初始化它們的刪除器在默認情況下也是對Base類型做delete一樣會觸發(fā)上述問題。3.2 正確做法與常見誤區(qū)正確的做法是在基類中聲明虛析構函數(shù)class Base { public: virtual ~Base() default; };這樣delete一個基類指針時運行時會通過虛表找到真正對象的析構函數(shù)先執(zhí)行派生類的析構邏輯再執(zhí)行基類的析構邏輯一切正常。一個常見的誤區(qū)是“我只要把所有類的析構函數(shù)都寫上virtual不就安全了嗎”理論上沒問題但實踐上這會帶來虛表的額外開銷。而且如果你的類根本不打算當基類寫了虛析構反而讓這個類的對象多一個vptr對象體積變大拷貝和移動性能也會受影響。實操建議是這樣的凡是設計為基類且會被多態(tài)刪除的類析構函數(shù)一律聲明為virtual。凡是明確不打算作為基類使用的類析構函數(shù)保持非虛甚至用final修飾把繼承這條路直接封死。不要用virtual來“賭”別人會不會繼承你的類規(guī)范要靠設計來定不靠亂加關鍵字。4. 純虛函數(shù)與抽象類多態(tài)設計的關鍵工具4.1 什么時候用純虛函數(shù)純虛函數(shù)的寫法是在虛函數(shù)聲明后面加 0class Shape { public: virtual void draw() 0; virtual ~Shape() default; };帶有純虛函數(shù)的類不能實例化這叫抽象類。抽象類的意義在于它定義了一組“接口契約”要求所有派生類必須實現(xiàn)這些純虛函數(shù)但仍然可以讓基類的某些通用邏輯保留實現(xiàn)供派生類復用。什么時候該用純虛函數(shù)我的判斷標準很簡單這個基類到底有沒有“合理的默認實現(xiàn)”。比如Shape::draw()你說它的默認實現(xiàn)是什么沒有任何一個“圖形”能憑空畫出自己所以抽象類合理。再比如某個日志系統(tǒng)的基類open()、write()、close()這種每一類日志器的實現(xiàn)都不同同樣適合用純虛函數(shù)。反過來如果基類的某個方法有合理的默認行為而且大多數(shù)派生類都愿意直接復用就應該用普通的虛函數(shù)降低派生類的實現(xiàn)負擔。 0這個寫法還有一個細節(jié)純虛函數(shù)也可以有函數(shù)體。換句話說你可以給純虛函數(shù)寫實現(xiàn)只是它仍然不能被直接實例化調(diào)用得通過派生類實現(xiàn)里顯式調(diào)用Base::func()。這個技巧在清理資源或者做公共邏輯的時候偶爾能用上但屬于相對少見的用法不要為了讓代碼看起來“高級”就亂用。4.2 接口繼承與實現(xiàn)繼承的權衡面向?qū)ο笤O計里一直有個爭論到底是面向接口編程還是面向?qū)崿F(xiàn)編程。落到C里情況比較特殊——C沒有像Java那種單獨的interface關鍵字接口類在C中通常就是“全是純虛函數(shù)的類”。這帶來一個好處一個類仍然可以通過多重繼承多個接口類同時只繼承一個實現(xiàn)類規(guī)避掉菱形繼承的大部分問題。在設計上我傾向于把“接口”和“實現(xiàn)”拆開。接口層職責只定義“能做什么”實現(xiàn)層負責“怎么做”。具體到代碼組織就是你常用的派生類應該繼承一個純接口類形成一個清晰的抽象邊界。這樣當后期需求變化時你往往只需要新增一個實現(xiàn)類而不用去改動已經(jīng)穩(wěn)定運行的上層代碼。不過也要說句公道話如果整個項目里所有類都套一層接口項目會迅速變成一個意大利面工廠。每個類都有虛表、有間接調(diào)用、有抽象層級調(diào)試起來非常痛苦。我自己見過的很多質(zhì)量不錯的項目里接口都是“按需使用”——體系邊界處需要多態(tài)擴展時引入接口內(nèi)部實現(xiàn)細節(jié)盡量用具體類型。5. 多態(tài)的性能代價與現(xiàn)代替代方案5.1 虛函數(shù)調(diào)用到底慢在哪虛函數(shù)不是魔法它的調(diào)用有一個繞不開的間接層運行時要通過vptr找到虛表再通過虛表找到函數(shù)地址。這個查找的過程本身非?？焱ǔ＞鸵粌蓚€指令的事。但它真正的開銷在于編譯器在虛函數(shù)調(diào)用點往往沒法知道最終調(diào)用的是哪個實現(xiàn)所以很多優(yōu)化都做不了。首當其沖的是內(nèi)聯(lián)。內(nèi)聯(lián)是C性能的重要來源之一但虛函數(shù)調(diào)用是間接的編譯器在編譯調(diào)用點時并不知道具體函數(shù)體是什么沒法內(nèi)聯(lián)。就算對象的類型在運行時其實非常明確編譯器依然出于謹慎放棄內(nèi)聯(lián)優(yōu)化。其次是分支預測和緩存。虛函數(shù)調(diào)用跳轉(zhuǎn)到的是一個“未知”的目標地址這會干擾指令緩存和分支預測器的正常工作。在一個極其注重性能的熱路徑上比如每秒調(diào)用百萬次的那種循環(huán)虛函數(shù)的性能代價就變得非常顯著了。我給一個直觀的參考對比一個普通成員函數(shù)調(diào)用和一個虛函數(shù)調(diào)用在同樣條件下虛函數(shù)調(diào)用的開銷通常是一個普通調(diào)用的一到三倍。這個差距在大多數(shù)業(yè)務代碼里根本看不出來但在數(shù)學計算、圖像處理、游戲引擎更新等高頻場景中可能就是壓垮性能的最后一根稻草。5.2 用std::variant和std::visit做靜態(tài)多態(tài)現(xiàn)代CC17之后提供了一種有意思的思路用std::variant加std::visit來替代一部分虛函數(shù)多態(tài)場景。std::variant是一個類型安全的聯(lián)合體它能在一組類型中保存任意一個類型的值std::visit則能根據(jù)當前持有的是哪個類型自動去調(diào)用對應的訪問函數(shù)。這種方式的好處是沒有虛表開銷沒有運行時的動態(tài)綁定編譯器能看到所有可能的分支從而可能生成非常高效的代碼甚至能針對每種類型單獨做優(yōu)化。很多對性能敏感的分支邏輯改用variant之后能得到實打?qū)嵉男阅芴嵘?。舉個例子一個圖形系統(tǒng)如果你需要在編譯時就確定“圖形類型集合”是有限的圓形、矩形、三角形那么用std::variantCircle, Rect, Triangle來存儲圖形比設計一整套Shape虛函數(shù)體系更高效。缺點當然也有類型集合是封閉的——你想增加一種新圖形必須修改variant類型定義和visit邏輯不像虛函數(shù)那樣天然支持擴展。這兩種方式的使用場景并不互斥。我的經(jīng)驗是需要運行時不可預知擴展的用虛函數(shù)類型集合固定且對性能敏感的用variant。讀懂并善用這兩種工具的差異比單方面推崇一種要靠譜得多。6. 常見問題與代碼層面的排查思路6.1 派生類函數(shù)沒有調(diào)用到位簽名不對還是忘了加virtual這是一個每年能上熱搜榜的經(jīng)典問題明明寫了同名同參的函數(shù)也用了基類指針結(jié)果調(diào)用的還是基類的版本。最常見的三個原因一是基類函數(shù)沒有聲明為virtual。加一句virtual就解決的事漏掉就變成隱藏了。二是簽名不匹配比如參數(shù)加了個const返回值類型不同派生類寫的函數(shù)其實是隱藏而非重寫。三是在基類函數(shù)的調(diào)用環(huán)境中傳入的類型是“切片”后的值拷貝子類是作為一個臨時副本被拷貝構造出來自然調(diào)不到派生類的虛函數(shù)。我推薦的做法是無腦給所有意圖重寫的派生類函數(shù)加overrideclass Derived : public Base { public: void draw() override; };這樣萬一簽名寫錯了編譯器會直接拒絕編譯而不是讓你在運行時困惑半天。6.2 構造函數(shù)中調(diào)用虛函數(shù)的正確姿勢前面說過構造函數(shù)里調(diào)虛函數(shù)不會觸發(fā)多態(tài)。但現(xiàn)實里總有人需要“構造時做點動態(tài)行為”。如果你真的遇到這種需求有幾種推薦的做法方法一把調(diào)虛函數(shù)的邏輯從構造函數(shù)挪出去變成一個公共的init()方法由構造完成后的代碼顯式調(diào)用。方法二用兩段式構造先構造出一個無初始化的裸對象再單獨調(diào)初始化函數(shù)。方法三如果必須在構造時知道類型可以考慮類型標簽或者奇異遞歸模板模式讓基類在編譯期就能拿到派生類的類型信息。不管選哪種原則都是不要在對象還沒有完全成型的時候假裝它已經(jīng)是最終的樣子。構造期的基本規(guī)則就是保守——只做與當前構造階段相關的事情。6.3 多態(tài)場景下拷貝與切片問題的處理值拷貝在繼承體系里會引起著名的“切片”問題把一個派生類對象賦值給一個基類對象派生類特有的部分會全部丟失只?；惖牟糠帧＿@就等于把一個具體的對象強行走了一遍“截斷”。如果你用這種切片后的基類對象去調(diào)用虛函數(shù)調(diào)到的自然只能是基類的版本。對策通常是兩條路一是盡量避免把基類對象當值來拷貝改傳指針或引用二是在需要復制多態(tài)對象的時候使用“克隆模式”class Base { public: virtual std::unique_ptrBase clone() const 0; }; class Derived : public Base { public: std::unique_ptrBase clone() const override { return std::make_uniqueDerived(*this); } };這樣拷貝一個派生類對象時多態(tài)的語義得以保留派生類的數(shù)據(jù)也不會丟。邏輯上很直接但在工程里真的是一個很少被寫對的地方值得多看兩遍。7. 我的一些實際心得關于C多態(tài)網(wǎng)上能搜到的資料確實很多但大多數(shù)都在講語法層面。我在實際項目里摸爬滾打這些年最大的體會是多態(tài)不是“為了用而用的語法糖”而是一種設計能力的體現(xiàn)。一個系統(tǒng)該在哪里引入多態(tài)該用什么形式引入這比“怎么寫虛函數(shù)”重要得多。提煉一下我的經(jīng)驗第一多態(tài)是為“變化點”服務的。如果你的需求列表里明確出現(xiàn)“未來會有新的類型加進來”那這里就是多態(tài)的用武之地如果你只是想讓代碼結(jié)構看起來更“面向?qū)ο蟆蹦欠炊沁^度設計的信號。第二虛函數(shù)的使用要克制。接口能少就少虛函數(shù)能不加就不加。多態(tài)帶來的靈活性是有代價的——性能、可讀性、調(diào)試難度每一項都要列入成本。第三把基類當契約來對待。一旦定義了一個基類并開放了虛函數(shù)它就變成了一種對外承諾改動基類的虛函數(shù)簽名或者刪除某個虛函數(shù)會波及所有派生類。所以基類的設計要慎重接口的變更要走嚴肅的討論流程。第四利用編譯器來管住自己。能用override就用能用final就用能在設計階段用“類不該被繼承”的final堵死歧義就用。工具是拿來保護代碼的不要覺得加了幾個關鍵字就貶低了代碼的水平。最后分享一個小小的排查技巧當你在多態(tài)場景下發(fā)現(xiàn)問題時不要急著打日志先在調(diào)試器里看看對象的實際類型是什么再確認一下函數(shù)調(diào)用斷點是否命中了虛表那一步。很多時候問題在類型層面就已經(jīng)顯示出來了。C多態(tài)這個話題表面上是語法題本質(zhì)上是設計與工程權衡的綜合題。把這套機制理解透了你不僅寫代碼會更有底氣和同事討論設計時也能抓住更本質(zhì)的東西。補充一個個人習慣我寫多態(tài)代碼時幾乎從不用virtual這個關鍵字去標注派生類的重寫函數(shù)一律用override。這個習慣幫我攔住過很多次簽名不匹配的隱性錯誤強烈建議你也養(yǎng)成它。