多態(tài)是C里最容易被“用起來很爽解釋起來含糊”的特性。很多朋友從Java、Python轉(zhuǎn)過來時(shí)覺得C的多態(tài)神秘又麻煩明明加了virtual有時(shí)候調(diào)用卻不走派生類明明基類析構(gòu)函數(shù)沒寫virtual程序卻崩得莫名其妙。我早在工作頭兩年也被這些東西折磨過后來把虛函數(shù)表、虛指針、構(gòu)造析構(gòu)期間的綁定規(guī)則這些底賬翻了一遍才算真正摸透了動(dòng)態(tài)綁定的脾氣。這篇文章想做的事情很簡(jiǎn)單把“C多態(tài)動(dòng)態(tài)綁定的核心機(jī)制”講透。你會(huì)看到編譯器在vptr和vtable背后搗鼓了什么也會(huì)看到為什么對(duì)象切片、構(gòu)造函數(shù)里調(diào)虛函數(shù)這類坑會(huì)讓新手抓狂。適合剛學(xué)完基礎(chǔ)語法、準(zhǔn)備進(jìn)階的C開發(fā)者也適合寫業(yè)務(wù)代碼時(shí)被“虛函數(shù)性能差”這種話搞到不敢用多態(tài)的人。讀完你至少能回答這幾個(gè)問題動(dòng)態(tài)綁定到底“動(dòng)”在哪個(gè)環(huán)節(jié)什么時(shí)候必須用多態(tài)什么時(shí)候該繞開它1. 先搞清楚靜態(tài)綁定和動(dòng)態(tài)綁定的差別1.1 從一段“看似多態(tài)”的代碼說起我見過很多新手寫出類似這樣的代碼#include iostream class Animal { public: virtual void speak() { std::cout Animal speaks\n; } }; class Dog : public Animal { public: void speak() override { std::cout Dog barks\n; } }; int main() { Animal a; Dog d; a d; // 賦值不是指針或引用 a.speak(); // 輸出什么 return 0; }如果你以為會(huì)打印“Dog barks”那說明對(duì)動(dòng)態(tài)綁定的理解還差一層。這段代碼輸出的還是“Animal speaks”。原因很簡(jiǎn)單a是一個(gè)Animal對(duì)象把d賦值給a時(shí)發(fā)生了對(duì)象切割Dog特有的部分被切掉了大對(duì)象賦值給小對(duì)象多態(tài)連發(fā)揮的機(jī)會(huì)都沒有。動(dòng)態(tài)綁定真正生效的場(chǎng)景是基類指針或者基類引用Animal* ptr d; ptr-speak(); // Dog barks Animal ref d; ref.speak(); // Dog barks這里的關(guān)鍵點(diǎn)在于編譯期看到的是Animal*但運(yùn)行時(shí)指針實(shí)際指向的是Dog對(duì)象。函數(shù)調(diào)用不再由靜態(tài)類型決定而是由動(dòng)態(tài)類型決定。這就是“動(dòng)”的含義——調(diào)用目標(biāo)在運(yùn)行時(shí)才確定。1.2 多態(tài)生效的三個(gè)前提條件想觸發(fā)動(dòng)態(tài)綁定這三個(gè)條件缺一不可必須有繼承關(guān)系派生類重寫了基類的虛函數(shù)。基類中該函數(shù)必須用virtual聲明派生類最好用override明確標(biāo)記。必須通過基類指針或基類引用調(diào)用不能用對(duì)象直接調(diào)用。有人會(huì)問為什么對(duì)象直接調(diào)用不行因?yàn)閷?duì)象類型在編譯期是固定的。你用Animal a聲明出來的變量?jī)?nèi)存布局就是Animal大小即使你塞進(jìn)去一個(gè)Dog也會(huì)被截?cái)喑葾nimal。指針和引用不同它們只是指向已有對(duì)象的“遙控器”不會(huì)改變對(duì)象本身的內(nèi)存布局所以編譯器只能延遲到運(yùn)行時(shí)去查它到底指向誰。從靜態(tài)綁定和動(dòng)態(tài)綁定的編譯期行為來看差別也很明顯綁定方式?jīng)Q策時(shí)機(jī)依據(jù)什么典型調(diào)用方式性能特點(diǎn)靜態(tài)綁定編譯期表達(dá)式的靜態(tài)類型普通函數(shù)、對(duì)象直接調(diào)用、非虛成員函數(shù)可內(nèi)聯(lián)、開銷低動(dòng)態(tài)綁定運(yùn)行期對(duì)象的動(dòng)態(tài)類型通過基類指針/引用調(diào)用虛函數(shù)間接跳轉(zhuǎn)、難內(nèi)聯(lián)靜態(tài)綁定有點(diǎn)像在飯店下單時(shí)直接點(diǎn)了“招牌菜菜單上寫明是哪個(gè)廚師做”廚師/菜品在編譯期就鎖定了。動(dòng)態(tài)綁定則像是拿著代金券進(jìn)店收銀員要到刷卡時(shí)才知道你能不能享受會(huì)員折扣。后者的靈活性正是我們?cè)O(shè)計(jì)可擴(kuò)展系統(tǒng)時(shí)最需要的。2. 虛函數(shù)表與虛指針動(dòng)態(tài)綁定背后的機(jī)制2.1 編譯器背地里生成的兩個(gè)東西動(dòng)態(tài)綁定不是魔法它在主流編譯器里都有統(tǒng)一且直觀的實(shí)現(xiàn)方式虛函數(shù)表vtable和虛指針vptr。每個(gè)含有虛函數(shù)包括繼承來的虛函數(shù)的類在編譯后通常會(huì)有兩個(gè)額外的東西一份虛函數(shù)表本質(zhì)是一個(gè)函數(shù)指針數(shù)組里面按順序保存這個(gè)類所有虛函數(shù)的地址。每個(gè)對(duì)象內(nèi)部增加一個(gè)隱藏成員即虛指針?biāo)赶蛩鶎兕悓?duì)應(yīng)的虛函數(shù)表。C標(biāo)準(zhǔn)其實(shí)沒有強(qiáng)制規(guī)定必須用vtablevptr實(shí)現(xiàn)多態(tài)不同編譯器可能有其他內(nèi)部方案。但現(xiàn)實(shí)是GCC、Clang、MSVC在主流平臺(tái)上都采用這個(gè)模型。所以理解這套機(jī)制基本就等于理解了真實(shí)編譯器的行為?？匆粋€(gè)最簡(jiǎn)單的類class Base { public: virtual void f1() {} virtual void f2() {} void notVirtual() {} };Base對(duì)象里會(huì)多出一個(gè)vptr一般來說sizeof(Base)比只有一個(gè)普通函數(shù)的類多一個(gè)指針寬度例如64位平臺(tái)上多8字節(jié)。這個(gè)vptr指向Base的虛表虛表里至少有兩個(gè)槽位分別保存f1和f2的地址。當(dāng)編譯器處理ptr-f1()時(shí)它做的事大致是取 ptr 指向的對(duì)象的 vptr 通過 vptr 找到 vtable 從 vtable 的對(duì)應(yīng)槽位取出函數(shù)地址 間接調(diào)用該地址整個(gè)過程比普通函數(shù)調(diào)用多了一到兩次內(nèi)存訪問和一次間接跳轉(zhuǎn)但這也是多態(tài)靈活性的來源。要是沒有這套機(jī)制編譯器就得在編譯期拍板調(diào)用哪個(gè)函數(shù)那就做不到了。2.2 單繼承下的虛表到底長(zhǎng)什么樣單繼承時(shí)派生類的虛表生成規(guī)則比較簡(jiǎn)單。假設(shè)派生類Derived重寫了f1又新增了虛函數(shù)f3class Derived : public Base { public: void f1() override {} virtual void f3() {} };那么Derived對(duì)象的vptr指向一張新的虛表這張?zhí)摫頃?huì)把重寫后的f1地址放在基類f1的位置f2地址照抄基類新增的f3追加在后面。這個(gè)布局有個(gè)重要推論基類指針看成Base*時(shí)它認(rèn)為自己指向的對(duì)象開頭就是Base的vptr而實(shí)際上Derived對(duì)象開頭也是這個(gè)東西只是內(nèi)容換成了Derived的虛表。所以編譯器只要“假裝”在看Base對(duì)象就能正確完成虛函數(shù)調(diào)用。這就是單繼承多態(tài)高效又自然的原因。多繼承就沒這么舒服了。如果Derived同時(shí)繼承Base1和Base2對(duì)象里通常會(huì)有兩個(gè)vptr分別指向與Base1子對(duì)象和Base2子對(duì)象對(duì)應(yīng)的虛表。從Base2*訪問Derived對(duì)象時(shí)指針可能還要做偏移修正。真實(shí)場(chǎng)景里能用單繼承就用單繼承多繼承帶來的心智負(fù)擔(dān)和調(diào)試成本都非常高動(dòng)態(tài)綁定也會(huì)因?yàn)椤皌his調(diào)整”變得更容易出問題。2.3 編譯器偷懶動(dòng)態(tài)綁定也能被“滅掉”有意思的是動(dòng)態(tài)綁定只是“可以”在運(yùn)行時(shí)分派編譯器在確定某些場(chǎng)景能提前推斷出結(jié)果時(shí)會(huì)做去虛化devirtualization。比如Dog d; d.speak();雖然speak是虛函數(shù)但這里對(duì)象靜態(tài)類型就是Dog編譯器會(huì)直接綁定到Dog::speak甚至可能內(nèi)聯(lián)。這不算動(dòng)態(tài)綁定只是語法上允許這么寫。還有一種情況Dog d; Animal ref d; ref.speak();如果編譯器能通過局部對(duì)象分析出ref綁定的就是d也有機(jī)會(huì)在優(yōu)化階段把它轉(zhuǎn)換為直接調(diào)用。所以“虛函數(shù)一定慢”這個(gè)說法要打折扣要看編譯器能不能做推斷。2.4 為什么對(duì)象切割會(huì)破壞動(dòng)態(tài)綁定回到第1.1節(jié)Animal a d這一步實(shí)際發(fā)生的是拷貝構(gòu)造。編譯器會(huì)把d里屬于Animal的部分復(fù)制到a然后a的vptr自然指向Animal的虛表。你可能會(huì)覺得“那我重寫一下拷貝賦值不就行了”不行任何拷貝操作都不會(huì)拷貝vptr因?yàn)関ptr是編譯器內(nèi)部管理的東西你無法在用戶代碼里直接修改它。對(duì)象一旦被切割它的動(dòng)態(tài)類型就永遠(yuǎn)變成基類了。這個(gè)坑在塞對(duì)象進(jìn)容器時(shí)特別常見。以前我見過有人寫std::vectorAnimal animals; animals.push_back(Dog{});然后遍歷調(diào)用speak()全部成了基類版本。要保留多態(tài)行為容器里應(yīng)該存放指針或智能指針這就是后文會(huì)提到的“多態(tài)容器”問題。3. 設(shè)計(jì)層面的多態(tài)從接口到工廠3.1 用純虛函數(shù)定義契約多態(tài)不止是語法更是一種設(shè)計(jì)工具。它的核心價(jià)值在于讓調(diào)用方只依賴抽象接口不依賴具體實(shí)現(xiàn)。經(jīng)典做法是用純虛函數(shù)定義接口類。class Shape { public: virtual ~Shape() default; virtual double area() const 0; virtual void draw() const 0; }; 0表示這個(gè)函數(shù)是純虛函數(shù)。含有純虛函數(shù)的類叫抽象類不能直接實(shí)例化。這樣做等于明確告訴使用者你必須在派生類里實(shí)現(xiàn)area()和draw()否則這個(gè)類沒法創(chuàng)建對(duì)象。接口類里的析構(gòu)函數(shù)必須寫上virtual并給默認(rèn)實(shí)現(xiàn)這是設(shè)計(jì)契約的一部分。后面第4部分會(huì)解釋為什么。抽象類的好處是調(diào)用方可以寫出完全不知道具體形狀代碼的邏輯void printArea(const Shape s) { std::cout area s.area() \n; }未來添加Triangle、EllipseprintArea一行都不用改。這種可擴(kuò)展性正是動(dòng)態(tài)綁定機(jī)制帶來的。3.2 override 和 final給重寫加上安全帶override不是必須的但我強(qiáng)烈建議每次重寫虛函數(shù)都加上。它的作用是告訴編譯器“我確實(shí)想重寫基類虛函數(shù)?！比绻惡灻静黄ヅ渚幾g器會(huì)直接報(bào)錯(cuò)而不是讓這個(gè)函數(shù)變成一個(gè)新的普通函數(shù)。沒有override時(shí)很容易犯簽名不匹配的錯(cuò)誤class Base { public: virtual void print(int x); }; class Derived : public Base { public: void print(double x); // 想重寫不這只是新函數(shù) };Derived里的double版本會(huì)隱藏基類的int版本。調(diào)用方如果持有Base*仍然調(diào)用基類版本持有Derived*調(diào)用時(shí)才會(huì)命中隱藏規(guī)則。這種“改了簽名但沒人提醒”的問題在代碼量大了以后非常難排查。final則是相反方向的控制它禁止某個(gè)虛函數(shù)被繼續(xù)重寫或者禁止某個(gè)類被繼承class Base { public: virtual void run(); // 可以被重寫 }; class Derived : public Base { public: void run() final; // Derived之后的類不能重寫run }; class Derived2 : public Derived { public: // void run() override; // 編譯錯(cuò)誤 };在設(shè)計(jì)穩(wěn)定層或者性能敏感的類時(shí)final能給編譯器更多信息有時(shí)候也能幫助去虛化。我個(gè)人的經(jīng)驗(yàn)是默認(rèn)用override只有明確想關(guān)閉繼承擴(kuò)展時(shí)才用final。3.3 工廠函數(shù) unique_ptr現(xiàn)代C多態(tài)的標(biāo)配組合多態(tài)和動(dòng)態(tài)內(nèi)存管理幾乎是伴生關(guān)系。裸指針容易泄漏C17之后我更推薦用std::unique_ptr來管理多態(tài)對(duì)象。#include memory #include stdexcept class Circle : public Shape { double r_; public: explicit Circle(double r) : r_(r) {} double area() const override { return 3.141592653589793 * r_ * r_; } void draw() const override {} }; class Rectangle : public Shape { double w_, h_; public: Rectangle(double w, double h) : w_(w), h_(h) {} double area() const override { return w_ * h_; } void draw() const override {} }; std::unique_ptrShape createShape(const std::string type) { if (type circle) { return std::make_uniqueCircle(1.0); } if (type rect) { return std::make_uniqueRectangle(2.0, 3.0); } throw std::invalid_argument(unknown shape type); }調(diào)用方auto s createShape(circle); s-draw(); // 動(dòng)態(tài)綁定 std::cout s-area();為什么用unique_ptr而不是Shape*因?yàn)閡nique_ptr的析構(gòu)函數(shù)會(huì)自動(dòng)調(diào)用delete而且它能正確觸發(fā)虛析構(gòu)把Circle和Shape的析構(gòu)函數(shù)按正確順序執(zhí)行。裸指針一旦忘記delete或者異常提前鋪開就會(huì)泄漏。unique_ptr還有一個(gè)好處它是獨(dú)占所有權(quán)語義清晰適合大多數(shù)工廠場(chǎng)景。3.4 多態(tài)容器別放對(duì)象放智能指針如果有一組不同形狀要一起處理很多人會(huì)想到std::vectorShape但這是第1章提過的對(duì)象切割陷阱。正確寫法std::vectorstd::unique_ptrShape shapes; shapes.push_back(std::make_uniqueCircle(1.0)); shapes.push_back(std::make_uniqueRectangle(2.0, 3.0)); for (const auto p : shapes) { p-draw(); }容器里放unique_ptr有幾個(gè)好處元素的動(dòng)態(tài)類型被完整保留容器析構(gòu)時(shí)自動(dòng)釋放所有對(duì)象多態(tài)遍歷時(shí)通過智能指針重載的operator-調(diào)用虛函數(shù)和裸指針語法一致。如果確實(shí)需要共享所有權(quán)比如多個(gè)觀察者都持有一個(gè)Shape那可以考慮std::shared_ptr。但共享所有權(quán)會(huì)帶來引用計(jì)數(shù)的原子操作開銷能用unique_ptr就用unique_ptr。4. 構(gòu)造函數(shù)、析構(gòu)函數(shù)與多態(tài)的愛恨情仇4.1 構(gòu)造函數(shù)里調(diào)虛函數(shù)為什么不走派生類版本這是新手最容易踩的坑基類構(gòu)造函數(shù)里調(diào)用某個(gè)虛函數(shù)本以為會(huì)調(diào)用派生類重寫后的版本結(jié)果調(diào)用了基類版本。class Base { public: Base() { init(); } virtual void init() { std::cout Base::init\n; } }; class Derived : public Base { public: void init() override { std::cout Derived::init\n; } }; int main() { Derived d; }我在學(xué)習(xí)階段預(yù)期輸出“Derived::init”實(shí)際輸出卻是“Base::init”。原因是C對(duì)象構(gòu)造的順序是先構(gòu)造基類部分再構(gòu)造派生類部分。當(dāng)基類構(gòu)造函數(shù)運(yùn)行時(shí)派生類成員還未初始化編譯器不敢讓虛函數(shù)調(diào)用跑到派生類里去因?yàn)榕缮惒糠稚胁淮嬖?。此時(shí)vptr被設(shè)置為指向基類的虛表所以虛函數(shù)調(diào)用會(huì)綁定到基類版本。更嚴(yán)格地說標(biāo)準(zhǔn)規(guī)定在基類構(gòu)造和析構(gòu)期間動(dòng)態(tài)類型被視為當(dāng)前正在構(gòu)造/析構(gòu)的這個(gè)類。所以init()里做任何跟派生類狀態(tài)相關(guān)的動(dòng)作都是不安全的。那如果init()被聲明為純虛函數(shù)會(huì)怎樣基類構(gòu)造函數(shù)調(diào)用純虛函數(shù)屬于未定義行為很多編譯器會(huì)在運(yùn)行時(shí)崩潰。千萬別這么寫。4.2 基類析構(gòu)函數(shù)為什么要 virtual如果你寫過Java可能不理解為什么C老是強(qiáng)調(diào)這件事。原因是C對(duì)象的刪除方式?jīng)Q定了析構(gòu)函數(shù)的調(diào)用時(shí)機(jī)必須正確。class Base { public: ~Base() {} // 非虛析構(gòu) }; class Derived : public Base { int* p new int(42); public: ~Derived() { delete p; } };然后這樣使用Base* b new Derived(); delete b;因?yàn)閎的靜態(tài)類型是Base*析構(gòu)函數(shù)又不是虛函數(shù)所以delete b時(shí)編譯器只調(diào)用Base::~Base()Derived的析構(gòu)函數(shù)根本不會(huì)執(zhí)行。p指向的int就泄漏了。更致命的是這種用法在C里其實(shí)是未定義行為不是“忘記調(diào)用”這么溫柔它可能在delete時(shí)直接崩潰。解決辦法很簡(jiǎn)單基類析構(gòu)函數(shù)聲明為virtual并給出定義class Base { public: virtual ~Base() default; };這樣delete b會(huì)先調(diào)用Derived::~Derived()再自動(dòng)調(diào)用Base::~Base()資源正常釋放。我的習(xí)慣是只要類里出現(xiàn)了任何一個(gè)虛函數(shù)就順手把析構(gòu)函數(shù)寫成virtual。就算現(xiàn)在用不到未來別人繼承你的類時(shí)也會(huì)安全得多。4.3 析構(gòu)函數(shù)里同樣別虛調(diào)用析構(gòu)期間的vptr變化方向和構(gòu)造時(shí)相反執(zhí)行Derived::~Derived()時(shí)派生類部分仍然有效但在析構(gòu)函數(shù)體執(zhí)行完后vptr會(huì)被調(diào)整到基類的虛表然后調(diào)用Base::~Base()。如果你在Base::~Base()里調(diào)用某個(gè)虛函數(shù)它也會(huì)綁定到Base版本而不是Derived版本。這個(gè)陷阱的現(xiàn)場(chǎng)版我見過有人在一個(gè)GUI基類的析構(gòu)函數(shù)里調(diào)用了一個(gè)virtual cleanup()想最后做點(diǎn)清理。結(jié)果清理邏輯永遠(yuǎn)跑的是基類版本派生類注冊(cè)的一些回調(diào)根本沒注銷。后來把清理動(dòng)作改成由外部顯式調(diào)用或者在派生類析構(gòu)函數(shù)里完成問題才解決。規(guī)則記牢構(gòu)造函數(shù)和析構(gòu)函數(shù)中當(dāng)前類的虛函數(shù)版本才是安全可用的。5. 動(dòng)態(tài)綁定的代價(jià)與優(yōu)化思路5.1 虛函數(shù)調(diào)用到底慢在哪說“虛函數(shù)慢”并不是空穴來風(fēng)但你要知道慢在哪幾個(gè)環(huán)節(jié)第一次取vptr和vtable是額外內(nèi)存訪問。從vtable取函數(shù)地址后是一次間接跳轉(zhuǎn)CPU難以預(yù)測(cè)跳轉(zhuǎn)目標(biāo)分支預(yù)測(cè)失敗的成本不低。編譯器很難對(duì)虛函數(shù)進(jìn)行內(nèi)聯(lián)即使函數(shù)體只有幾行。如果虛函數(shù)訪問了大量無法緩存的數(shù)據(jù)cache miss會(huì)進(jìn)一步放大開銷。但實(shí)際測(cè)量的結(jié)果通常是一次普通虛函數(shù)調(diào)用比普通函數(shù)多幾納秒除非函數(shù)體真的極短并且處于千萬級(jí)循環(huán)里否則這點(diǎn)開銷很難被感知。我見過有人為了“性能”把本應(yīng)多態(tài)的代碼改成一大堆switch分支結(jié)果可維護(hù)性直線下降性能提升卻連profile數(shù)據(jù)都看不出明顯差異。給團(tuán)隊(duì)的教訓(xùn)是先量化再優(yōu)化。5.2 什么時(shí)候應(yīng)該避開動(dòng)態(tài)綁定當(dāng)然也有真正需要避開動(dòng)態(tài)綁定的場(chǎng)景for循環(huán)內(nèi)對(duì)小型對(duì)象高頻調(diào)用虛函數(shù)且函數(shù)體非常短。延遲和資源極其敏感的系統(tǒng)比如硬實(shí)時(shí)、嵌入式驅(qū)動(dòng)。固定類型集合、永遠(yuǎn)不會(huì)增加新類型的領(lǐng)域模型。這些場(chǎng)景可以做性能測(cè)試如果虛函數(shù)調(diào)用出現(xiàn)在profile熱區(qū)頂部再考慮替換方案。5.3 替代方案CRTP和std::variant如果類型集合固定且編譯期就能確定可以用CRTPCuriously Recurring Template Pattern實(shí)現(xiàn)靜態(tài)多態(tài)template typename Derived class ShapeBase { public: double area() const { return static_castconst Derived*(this)-areaImpl(); } }; class Square : public ShapeBaseSquare { public: double areaImpl() const { return side_ * side_; } double side_ 1.0; };這里的static_cast在編譯期完成不需要虛表和vptr因此可以內(nèi)聯(lián)性能接近手寫非虛版本。缺點(diǎn)是類型集合被模板封閉不能再像運(yùn)行時(shí)多態(tài)那樣保存到vectorBase*里統(tǒng)一處理。如果類型集合固定且可枚舉用std::variant代替繼承也是一種現(xiàn)代C思路using ShapeVariant std::variantCircle, Rectangle; double area(const ShapeVariant s) { return std::visit([](const auto shape) { return shape.area(); }, s); }std::visit本質(zhì)上會(huì)根據(jù)variant當(dāng)前的索引在編譯期生成分支不會(huì)侵入每個(gè)對(duì)象增加vptr對(duì)簡(jiǎn)單值類型很友好。但它要求所有類型在編譯期聲明不支持用戶后續(xù)擴(kuò)展。所以它適合“封閉多態(tài)”而運(yùn)行時(shí)虛函數(shù)適合“開放多態(tài)”。做架構(gòu)決策時(shí)先想清楚你的類型集是封閉還是開放。6. 常見問題與排查技巧實(shí)錄6.1 六個(gè)高頻錯(cuò)誤速查表下面這些是我在實(shí)際代碼評(píng)審和調(diào)試中反復(fù)遇到的問題整理成表錯(cuò)誤現(xiàn)象可能原因解決方案基類指針delete后內(nèi)存泄漏基類析構(gòu)函數(shù)不是virtual把析構(gòu)函數(shù)聲明為virtual或使用智能指針明明重寫了函數(shù)調(diào)用還是基類版本函數(shù)簽名跟基類不完全一致變成了隱藏用override讓編譯器檢查簽名調(diào)用總是基類版本但虛函數(shù)和簽名都沒問題通過對(duì)象調(diào)用發(fā)生對(duì)象切割改用指針/引用容器里放智能指針構(gòu)造函數(shù)中調(diào)用虛函數(shù)結(jié)果不是派生類版本基類構(gòu)造期間動(dòng)態(tài)類型被限定為基類不要依賴構(gòu)造期間的虛調(diào)用改為顯式二次初始化析構(gòu)函數(shù)崩潰或調(diào)用空函數(shù)析構(gòu)函數(shù)中調(diào)用已變成純虛的函數(shù)析構(gòu)期間不要依賴虛分派把清理邏輯收斂到當(dāng)前類明明調(diào)用了派生類函數(shù)但行為固定基類函數(shù)沒有聲明virtual給基類函數(shù)加上virtual派生類加override這張表的每一項(xiàng)都是我踩過或者幫別人查過的坑。尤其是第一條和第三條出現(xiàn)頻率太高值得寫進(jìn)團(tuán)隊(duì)C編碼規(guī)范的顯著位置。6.2 如何定位“虛函數(shù)沒生效”的問題排查時(shí)我通常按這樣的順序走先確認(rèn)調(diào)用表達(dá)式是通過指針或引用而不是對(duì)象。確認(rèn)基類成員函數(shù)確實(shí)帶virtual關(guān)鍵字。確認(rèn)派生類函數(shù)簽名與基類完全一致包括const限定、參數(shù)類型、返回值協(xié)變。用typeid打印對(duì)象的動(dòng)態(tài)類型確認(rèn)指針指向的到底是什么對(duì)象。比如typeid測(cè)試#include typeinfo Animal* p new Dog(); std::cout typeid(*p).name() \n; // 應(yīng)該包含Dog如果typeid顯示Dog但調(diào)用仍是Animal版本那幾乎可以確定是簽名不匹配或者隱藏問題。如果typeid顯示Animal那多半是對(duì)象切割或者指針實(shí)際指向的就不是Dog。6.3 謹(jǐn)慎使用 dynamic_cast 和 RTTI動(dòng)態(tài)綁定時(shí)代我們不太需要向下轉(zhuǎn)型因?yàn)楹玫亩鄳B(tài)設(shè)計(jì)應(yīng)該讓基類接口覆蓋所有派生類行為。但偶爾還是會(huì)遇到必須使用Derived特有接口的情況Shape* s getShape(); if (auto* c dynamic_castCircle*(s)) { c-setRadius(10.0); }dynamic_cast依賴RTTI需要在運(yùn)行時(shí)檢查類型信息開銷比虛函數(shù)調(diào)用高而且使用它也暗示設(shè)計(jì)可能存在裂縫。能用虛函數(shù)表達(dá)的邏輯就不要用向下轉(zhuǎn)型。如果確實(shí)頻繁需要向下轉(zhuǎn)型可以先停下來思考是不是基類接口設(shè)計(jì)得不完整把“設(shè)置半徑”這種操作提升為虛函數(shù)是不是更合理現(xiàn)代編譯器可以開啟-fno-rtti來禁用RTTI部分性能敏感項(xiàng)目會(huì)這么做。一旦關(guān)閉dynamic_cast就不能用了這也會(huì)反過來逼你做出更干凈的多態(tài)設(shè)計(jì)。6.4 多態(tài)與智能指針傳參細(xì)節(jié)傳遞多態(tài)對(duì)象給函數(shù)時(shí)傳const Shape通常比傳unique_ptrShape更合理。因?yàn)榍罢弑磉_(dá)“只讀觀察一個(gè)形狀”不轉(zhuǎn)移所有權(quán)后者強(qiáng)制要求調(diào)用方轉(zhuǎn)移指針語義笨重。只有在函數(shù)確實(shí)要接管對(duì)象生命周期時(shí)才傳unique_ptr。另一個(gè)小技巧是不要用shared_ptr做默認(rèn)參數(shù)除非你真的共享所有權(quán)。我用shared_ptr時(shí)經(jīng)常在代碼評(píng)審中問“這里到底誰還持有對(duì)象”往往問完之后發(fā)現(xiàn)大多數(shù)地方只需要裸指針或引用。裸指針作為“非擁有觀察者”在C里是合理的只要確保它不是new出來的責(zé)任主體就行。6.5 一個(gè)讓我印象深刻的教訓(xùn)說一個(gè)來自真實(shí)項(xiàng)目的例子。某個(gè)跨平臺(tái)插件系統(tǒng)里基類Plugin定義了虛函數(shù)initialize()但有一個(gè)插件在Plugin構(gòu)造函數(shù)中調(diào)用了initialize()本意是讓所有子類構(gòu)造時(shí)自動(dòng)初始化。結(jié)果這個(gè)插件加載后總是沒有初始化狀態(tài)排查了很久。最后發(fā)現(xiàn)就是第4.1節(jié)的問題基類構(gòu)造期間調(diào)用的是基類版本子類重寫根本沒參與。后來改成了這樣的兩步式方案子類構(gòu)造函數(shù)里顯式調(diào)用initialize()或者提供一個(gè)獨(dú)立的start()方法由外部生命周期管理器統(tǒng)一調(diào)用。這個(gè)教訓(xùn)讓我把“構(gòu)造函數(shù)中調(diào)用虛函數(shù)”寫進(jìn)了團(tuán)隊(duì)“堅(jiān)決不要做”清單。最后再分享一個(gè)我的實(shí)踐習(xí)慣每當(dāng)我新設(shè)計(jì)一個(gè)類繼承體系我會(huì)先寫一小段使用代碼想象調(diào)用方怎么使用這些類。如果調(diào)用方需要頻繁知道“實(shí)際類型”那說明接口設(shè)計(jì)不夠好如果基類接口能覆蓋所有操作多態(tài)就能讓你舒服地“只認(rèn)接口不認(rèn)實(shí)現(xiàn)”。這種思路用久了你會(huì)發(fā)現(xiàn)動(dòng)態(tài)綁定并不是什么黑魔法它只是編譯器在運(yùn)行時(shí)給你保留了一層“重新決策”的能力而你要做的是讓這層決策發(fā)生在正確的地方并且別在構(gòu)造析構(gòu)這種關(guān)鍵時(shí)刻給它添亂。C多態(tài)的性能開銷是真實(shí)存在的但絕大多數(shù)業(yè)務(wù)代碼根本到不了那個(gè)需要擔(dān)心它的地步。真正容易出問題的往往是對(duì)vptr生命周期理解不足或者濫用向下轉(zhuǎn)型。把虛函數(shù)表、虛指針、構(gòu)造析構(gòu)期間的類型變化都搞清楚后續(xù)再談優(yōu)化、架構(gòu)和設(shè)計(jì)都會(huì)穩(wěn)得多。