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