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