那天下午A同學(xué)把一段代碼發(fā)過(guò)來(lái)問(wèn)為什么編譯器給出的報(bào)錯(cuò)信息指得七零八落。代碼本身不長(zhǎng)是類模板里引用后面才定義的成員還有一處成員函數(shù)返回類型沒(méi)帶類名限定?？雌饋?lái)都是語(yǔ)法背得挺熟的寫法一編譯就炸。我逐行拆完發(fā)現(xiàn)坑全擠在四個(gè)點(diǎn)上類的作用域、類的實(shí)例化、類對(duì)象模型、this 指針。這四個(gè)詞幾乎是每一本 C 教材的必講章節(jié)但多數(shù)人只是把結(jié)論記住了一旦編譯器行為跟直覺(jué)不一致就完全不知道該往哪兒查。這篇文章我想把這條鏈子重新捋一遍不按教材的目錄順序念而是按編譯器到底怎么想的順序講。四個(gè)概念之間其實(shí)是因果關(guān)系類的作用域決定了名字怎么找類的實(shí)例化決定了內(nèi)存什么時(shí)候給類對(duì)象模型決定了這塊內(nèi)存里擺了些什么而 this 指針則是對(duì)象模型的一個(gè)直接推論——成員函數(shù)怎么知道自己該操作哪個(gè)對(duì)象。搞清這條因果鏈很多看起來(lái)莫名其妙的報(bào)錯(cuò)和運(yùn)行時(shí)行為反而會(huì)變得非常好解釋。內(nèi)容偏基礎(chǔ)但不會(huì)停留在是什么。每個(gè)點(diǎn)我都會(huì)配上能直接運(yùn)行的代碼、sizeof 的實(shí)測(cè)結(jié)果、以及我在實(shí)際項(xiàng)目里踩過(guò)的具體坑。適合剛學(xué)完類和對(duì)象語(yǔ)法、正在被各種詭異行為折磨的同學(xué)也適合已經(jīng)寫了幾年、但對(duì)象模型這塊一直是模糊印象的開發(fā)者重新校準(zhǔn)一遍。1. 四個(gè)概念其實(shí)是一條鏈先把關(guān)系理清楚1.1 從一次典型的編譯失敗說(shuō)起先看一段能讓編譯器直接拒絕的代碼這段代碼是我用來(lái)給別人講作用域時(shí)最常用的例子class Buffer { public: Handle get() { return Handle{}; } // 編譯報(bào)錯(cuò)Handle 未聲明 using Handle int; };報(bào)錯(cuò)信息大概意思是Handle在這個(gè)位置不是一個(gè)類型名。很多人第一反應(yīng)是我在類里面定義了Handle啊怎么會(huì)找不到。問(wèn)題就在于函數(shù)返回類型的名字查找發(fā)生在它出現(xiàn)的位置而不是在類定義結(jié)束之后。Handle的聲明在后面此處還不可見(jiàn)于是查找失敗。把它改成先聲明類型、后寫函數(shù)或者把返回類型挪到類外定義并使用尾置返回類型問(wèn)題立刻消失class Buffer { public: using Handle int; Handle get() { return Handle{}; } // 正常 };這個(gè)例子說(shuō)明的第一個(gè)道理是類是一個(gè)作用域但它不是一個(gè)整體生效的作用域。類作用域內(nèi)部的名字可見(jiàn)性受聲明順序約束。而成員函數(shù)體是例外它被當(dāng)作在類完全定義之后才處理所以函數(shù)體里可以直接引用后面聲明的成員。這個(gè)細(xì)節(jié)差異正是類的作用域這一節(jié)要講的核心。1.2 為什么必須先講作用域再講實(shí)例化我見(jiàn)過(guò)不少人學(xué)這塊的順序是反的先背類是模板對(duì)象是實(shí)例再背成員函數(shù)不占對(duì)象空間最后背this 是隱藏參數(shù)。三條都背下來(lái)了但串不起來(lái)。真正的依賴關(guān)系是這樣的——編譯器在處理類定義時(shí)先建立一個(gè)作用域把所有成員名字登記進(jìn)去等到定義對(duì)象時(shí)才按這個(gè)作用域里登記的信息去算大小、分配內(nèi)存算大小的規(guī)則就是對(duì)象模型而成員函數(shù)之所以能操作對(duì)象是因?yàn)榫幾g器在函數(shù)簽名里偷偷加了一個(gè)指向?qū)ο蟮膮?shù)也就是 this。換個(gè)說(shuō)法作用域決定了有哪些成員實(shí)例化決定了什么時(shí)候真的存在一個(gè)對(duì)象對(duì)象模型決定了這個(gè)對(duì)象占用哪些字節(jié)this 決定了函數(shù)怎么找到這些字節(jié)。少了任何一環(huán)后面都會(huì)出現(xiàn)無(wú)法解釋的現(xiàn)象。比如常見(jiàn)的疑問(wèn)為什么空類 sizeof 是 1答案在對(duì)象模型為什么 const 成員函數(shù)不能改成員答案在 this 的類型為什么類外的成員函數(shù)定義要寫兩遍類名答案在作用域。2. 類的作用域編譯器找名字的那張地圖2.1 類作用域到底新增了什么每次寫class X { ... };編譯器就打開了一個(gè)新的作用域比它所在的外圍作用域更內(nèi)層。所有在類體內(nèi)聲明的名字——成員變量、成員函數(shù)、嵌套類型、枚舉、類型別名——都登記在這個(gè)作用域里。在類內(nèi)直接寫名字編譯器會(huì)先在類作用域找找不到再往外層找在類外想訪問(wèn)必須用X::限定否則它會(huì)從當(dāng)前所在的作用域開始找很可能找到別的東西或者根本找不到。int count 100; // 全局變量 class Counter { public: void reset() { count 0; } // 改的是成員還是全局 int count 0; // 成員 };這段代碼里reset改的是成員count全局的count毫發(fā)無(wú)損。原因就是類作用域比全局作用域更內(nèi)層內(nèi)層優(yōu)先。如果你確實(shí)想改全局那個(gè)得寫::count 0。這個(gè)規(guī)則看起來(lái)平平無(wú)奇但在實(shí)際項(xiàng)目里非常容易出事——某個(gè)成員名字不小心和全局函數(shù)同名或者在派生類里重名就會(huì)出現(xiàn)我明明改了變量行為卻沒(méi)變的情況排查半天。類作用域還有一個(gè)重要特點(diǎn)它不會(huì)像命名空間那樣被using整個(gè)拉進(jìn)來(lái)你只能通過(guò)using聲明把單個(gè)名字暴露出去。這意味著類作用域是相對(duì)封閉的這對(duì)封裝是好事但也意味著類外訪問(wèn)必須老老實(shí)實(shí)寫限定符。2.2 聲明順序帶來(lái)的兩個(gè)不同世界類內(nèi)部的聲明順序?qū)γ植檎业挠绊懛殖蓛煞N截然不同的情況這一點(diǎn)很多資料一句話帶過(guò)其實(shí)值得單獨(dú)說(shuō)清楚。第一種是非成員函數(shù)體之外的位置包括成員變量的類型、函數(shù)參數(shù)類型、返回類型、using別名定義本身。這些位置的名字查找發(fā)生在聲明點(diǎn)按順序生效只能看到前面已經(jīng)聲明的東西。前面那個(gè)Handle的例子就是這一類。第二種是類完成定義之后才處理的位置標(biāo)準(zhǔn)里叫完整類上下文主要包括成員函數(shù)體、默認(rèn)實(shí)參、noexcept說(shuō)明符、默認(rèn)成員初始化器。這些位置的名字查找會(huì)把整個(gè)類作用域視為可見(jiàn)所以可以引用后面才聲明的成員class Widget { public: void show() { value 1; } // 合法value 在后面聲明 int get(int k limit) const { // 合法默認(rèn)實(shí)參可用后面的成員 return value k; } private: int value 0; int limit 10; };這解釋了為什么有時(shí)候先引用后聲明能編譯通過(guò)有時(shí)候又不行——完全取決于你寫在哪個(gè)位置。我自己的習(xí)慣是盡量不依賴這個(gè)特性成員變量統(tǒng)一寫在類的最前面函數(shù)寫在后面。好處是閱讀時(shí)不用來(lái)回跳壞處是有人說(shuō)這樣不符合接口在前、實(shí)現(xiàn)在后的風(fēng)格。這個(gè)問(wèn)題沒(méi)有標(biāo)準(zhǔn)答案但至少要清楚規(guī)則而不是靠試錯(cuò)。2.3 類外定義成員函數(shù)時(shí)返回類型為什么不在類作用域里這個(gè)問(wèn)題幾乎每個(gè)初學(xué)者都問(wèn)過(guò)。先看代碼class List { public: using Iter int*; Iter begin(); }; 要寫成 Iter List::begin() { ... } // 錯(cuò)Iter 在這里不可見(jiàn) List::Iter List::begin() { ... } // 對(duì)原因在于名字查找的方向是從左往右。編譯器讀到返回類型Iter的時(shí)候還沒(méi)讀到List::begin自然不知道這次查找應(yīng)該進(jìn)入List的作用域所以它只能在全局作用域里找找不到就報(bào)錯(cuò)。等它讀到List::begin才切換到類作用域但返回類型早就解析過(guò)了。解決辦法有兩個(gè)。一是把返回類型寫全List::Iter缺點(diǎn)是嵌套類型一多簽名會(huì)長(zhǎng)得沒(méi)法看。二是用尾置返回類型把返回類型挪到函數(shù)名后面此時(shí)已經(jīng)在類作用域內(nèi)了auto List::begin() - Iter { ... } // 干凈我在實(shí)際項(xiàng)目里更傾向第二種尤其是返回類型是模板嵌套依賴類型的時(shí)候尾置寫法幾乎是唯一可讀的選擇。這里有個(gè)小注意尾置返回類型和前置返回類型在語(yǔ)義上完全等價(jià)沒(méi)有性能差異純粹是可讀性和名字查找的便利。2.4 嵌套類、枚舉與繼承帶來(lái)的作用域疊加嵌套類是類作用域里再開一層。Outer::Inner這樣的類型在Outer的成員函數(shù)里可以直接寫Inner在類外必須寫Outer::Inner。這里最容易踩的坑是嵌套類不能直接訪問(wèn)外層類的非靜態(tài)成員。原因是嵌套類沒(méi)有隱含的this它和外層類的對(duì)象之間沒(méi)有綁定關(guān)系除非你把外層對(duì)象以參數(shù)或引用的形式傳進(jìn)去。class Outer { int secret 42; public: class Inner { public: int peek(Outer o) { return o.secret; } // 必須顯式傳對(duì)象 }; };繼承則是在作用域?qū)用嫘纬梢环N覆蓋關(guān)系。派生類的作用域被視為嵌套在基類作用域內(nèi)部所以在派生類里查找名字時(shí)先找派生類找不到再找基類。這帶來(lái)一個(gè)常被忽視的現(xiàn)象派生類的同名成員會(huì)完全隱藏基類的同名成員不管簽名是否相同?；愑袀€(gè)void foo()派生類有個(gè)void foo(int)在派生類里寫foo()會(huì)報(bào)錯(cuò)因?yàn)榫幾g器在派生類作用域里發(fā)現(xiàn)了foo這個(gè)名字就停止向外查找而它又找不到無(wú)參版本。想用基類版本必須寫B(tài)ase::foo()或者在派生類里加一句using Base::foo;。枚舉也有類似的歷史包袱。傳統(tǒng)enum把枚舉項(xiàng)的名字泄漏到外層作用域兩個(gè)不同的 enum 定義相同的枚舉項(xiàng)名字就會(huì)沖突enum class把名字鎖在枚舉自己的作用域里用的時(shí)候必須寫EnumName::Item。我在新代碼里一律用enum class一是避免名字污染二是它不會(huì)隱式轉(zhuǎn)換成整數(shù)能擋掉一批類型混用的錯(cuò)誤。3. 類的實(shí)例化從圖紙到實(shí)體都發(fā)生了什么3.1 類只是圖紙定義它不占用任何對(duì)象內(nèi)存先把一個(gè)容易被含糊過(guò)去的事實(shí)說(shuō)死定義類不會(huì)為任何對(duì)象分配內(nèi)存。編譯器在這個(gè)階段做的事只有檢查語(yǔ)法、登記成員信息、構(gòu)建類型描述產(chǎn)出的東西主要在編譯器的符號(hào)表里最終體現(xiàn)在可執(zhí)行文件的元信息里對(duì)象內(nèi)存一個(gè)字節(jié)都不會(huì)給。類比一下類是建筑圖紙對(duì)象是照?qǐng)D紙蓋出來(lái)的房子。圖紙本身不占地你在圖紙上改多少遍只要不蓋房子就沒(méi)有混凝土消耗。這個(gè)比喻雖然老但能解釋很多現(xiàn)象比如為什么可以在頭文件里被無(wú)數(shù)個(gè)源文件包含卻不會(huì)產(chǎn)生重復(fù)定義問(wèn)題類定義可以在多個(gè)翻譯單元中出現(xiàn)只要完全一致為什么靜態(tài)成員變量的定義必須放到類外它是一個(gè)實(shí)體需要分配存儲(chǔ)。實(shí)例化的動(dòng)作由定義對(duì)象觸發(fā)class Point { public: int x 0; int y 0; void move(int dx, int dy) { x dx; y dy; } }; Point p; // 這里才分配內(nèi)存 Point* ptr nullptr; // 指針本身占內(nèi)存但沒(méi)有 Point 對(duì)象Point*只是存了個(gè)地址此時(shí)并沒(méi)有任何Point對(duì)象存在。指針大小固定和Point的大小無(wú)關(guān)這一點(diǎn)在面試?yán)锉粏?wèn)爛了但真正理解指針不持有對(duì)象能幫你避免很多懸空訪問(wèn)。有一個(gè)例外需要說(shuō)明類模板的實(shí)例化時(shí)機(jī)和普通類不同。模板定義本身不產(chǎn)生任何代碼只有當(dāng)它被具體類型實(shí)例化時(shí)編譯器才生成對(duì)應(yīng)的類和成員函數(shù)。這也是為什么模板代碼出問(wèn)題時(shí)報(bào)錯(cuò)信息常常長(zhǎng)得離譜——錯(cuò)誤發(fā)生在實(shí)例化點(diǎn)而不是你寫代碼的地方。解決模板報(bào)錯(cuò)的經(jīng)驗(yàn)是先把模板改成具體類型試一遍確認(rèn)邏輯沒(méi)問(wèn)題再換回模板能省掉一大半排查時(shí)間。3.2 對(duì)象大小的構(gòu)成從 sizeof 反推布局對(duì)象的大小由三部分組成非靜態(tài)成員變量的大小、為滿足對(duì)齊要求插入的填充字節(jié)、以及存在虛函數(shù)時(shí)可能存在的虛表指針。靜態(tài)成員變量、成員函數(shù)、類型別名、嵌套類型統(tǒng)統(tǒng)不計(jì)入sizeof。class A { public: void f() { } static int s; using Ptr int*; private: char c; };實(shí)測(cè)sizeof(A)是 1。成員函數(shù)f不進(jìn)對(duì)象靜態(tài)成員s存在靜態(tài)區(qū)類型別名和嵌套類型不占空間只剩一個(gè)char。如果加上一個(gè)intclass B { char c; int i; };sizeof(B)在常見(jiàn)的 64 位平臺(tái)上一般是 8不是 5。因?yàn)閕nt要求起始地址是 4 的倍數(shù)char后面補(bǔ)了 3 個(gè)字節(jié)總大小是 8同時(shí)也是 4 的倍數(shù)結(jié)構(gòu)體整體大小要補(bǔ)到最大對(duì)齊數(shù)的整數(shù)倍。這里有個(gè)非常實(shí)用的優(yōu)化技巧很多人不知道調(diào)整成員聲明順序可以減小對(duì)象大小。class C1 { char a; int b; char c; }; // 通常 sizeof 是 12 class C2 { int b; char a; char c; }; // 通常 sizeof 是 8C1的布局是 a(1) 填充(3) b(4) c(1) 填充(3)C2是 b(4) a(1) c(1) 填充(2)。同樣三個(gè)成員順序不同差了 4 個(gè)字節(jié)。如果一個(gè)類會(huì)被創(chuàng)建上百萬(wàn)次這 4 字節(jié)乘以對(duì)象數(shù)量可能就是幾十兆的差距。我現(xiàn)在的習(xí)慣是成員按類型大小從大到小排列double、指針、int、short、char、bool依次往下能省掉大部分填充。提示sizeof的結(jié)果取決于編譯器和目標(biāo)平臺(tái)的對(duì)齊規(guī)則不同環(huán)境下同一個(gè)類的大小可能不同。涉及二進(jìn)制序列化或者跨進(jìn)程共享內(nèi)存的場(chǎng)景必須顯式確認(rèn)布局不能憑 sizeof 猜。3.3 空類為什么是 1 字節(jié)這個(gè)問(wèn)題幾乎必被問(wèn)到?？疹悰](méi)有任何成員sizeof卻是 1原因是語(yǔ)言要求每個(gè)對(duì)象都必須有唯一的地址。如果空類大小為 0那么連續(xù)創(chuàng)建兩個(gè)對(duì)象它們的內(nèi)存地址就會(huì)相同a b成立這會(huì)讓指針比較、數(shù)組下標(biāo)、容器實(shí)現(xiàn)全部失去意義。為了區(qū)分不同的對(duì)象編譯器給空類分配至少 1 個(gè)字節(jié)。class Empty { }; Empty a, b; // a ! b 恒成立還有一個(gè)延伸現(xiàn)象空類作為基類時(shí)為了不讓基類子對(duì)象占據(jù)獨(dú)立地址語(yǔ)言引入了空基類優(yōu)化派生類的大小不因?yàn)槔^承空類而增加。但同一個(gè)空基類被繼承多次就不行那屬于多重繼承的范疇會(huì)涉及到基類子對(duì)象的地址必須互不相同的問(wèn)題。這些細(xì)節(jié)平時(shí)寫業(yè)務(wù)代碼用不上但在寫序列化、內(nèi)存池、類型擦除組件時(shí)會(huì)直接影響布局計(jì)算必須心里有數(shù)。3.4 構(gòu)造順序與實(shí)例化的完整時(shí)序一個(gè)對(duì)象從無(wú)到有發(fā)生的事按順序是分配存儲(chǔ)空間 → 初始化基類子對(duì)象 → 初始化非靜態(tài)成員按聲明順序不是初始化列表順序→ 執(zhí)行構(gòu)造函數(shù)體。這個(gè)順序是強(qiáng)制規(guī)定的和你在初始化列表里寫的順序無(wú)關(guān)。class Order { int a; int b; public: Order() : b(2), a(1) { } // 實(shí)際仍是先初始化 a再 b };如果兩個(gè)成員的初始化有依賴關(guān)系順序?qū)懛戳司蜁?huì)讀到未初始化的值而且這種錯(cuò)誤往往不會(huì)立刻崩潰只是在某些編譯器優(yōu)化級(jí)別下表現(xiàn)異常排查起來(lái)極其痛苦。我的做法是初始化列表的順序永遠(yuǎn)和成員聲明順序保持一致一眼就能對(duì)上同時(shí)打開編譯器的順序警告。還有一點(diǎn)值得提只有定義對(duì)象才會(huì)調(diào)用構(gòu)造函數(shù)。聲明一個(gè)返回類型的對(duì)象、聲明一個(gè)函數(shù)指針、定義一個(gè)引用都不會(huì)觸發(fā)構(gòu)造。以前有個(gè)同學(xué)問(wèn)我為什么我把構(gòu)造函數(shù)里加了個(gè)打印運(yùn)行時(shí)一次都沒(méi)輸出看了代碼發(fā)現(xiàn)他定義的是函數(shù)聲明編譯器把它解析成了返回對(duì)象的函數(shù)——就是最經(jīng)典的 vexing parse。4. 類對(duì)象模型內(nèi)存里到底擺了些什么4.1 成員函數(shù)不占對(duì)象空間這是理解對(duì)象模型的第一塊磚很多人第一次聽(tīng)到成員函數(shù)不占對(duì)象內(nèi)存會(huì)覺(jué)得不可思議既然不占那它怎么知道該操作哪個(gè)對(duì)象的成員答案就是第五節(jié)的 this 指針但在這里先把不占這件事講透。成員函數(shù)在編譯之后本質(zhì)上就是普通的自由函數(shù)只不過(guò)第一個(gè)參數(shù)被編譯器偷偷加上了對(duì)象指針。它存在代碼段所有同類對(duì)象共享同一份指令不因?yàn)槟阌?100 個(gè)對(duì)象就復(fù)制 100 份。只有這樣類才能不因?yàn)楣δ軓?fù)雜而膨脹——你可以給一個(gè)類寫 50 個(gè)成員函數(shù)sizeof一個(gè)字節(jié)都不會(huì)變。class Calc { int total 0; public: void add(int v) { total v; } void clear() { total 0; } };sizeof(Calc)在常見(jiàn)平臺(tái)上就是 4和只有一個(gè)add方法時(shí)完全一樣。這個(gè)特性是 C 相比某些純面向?qū)ο笳Z(yǔ)言在內(nèi)存上的優(yōu)勢(shì)之一行為不占對(duì)象空間只有數(shù)據(jù)占。更細(xì)一點(diǎn)虛函數(shù)會(huì)影響對(duì)象大小但影響的方式不是把 50 個(gè)虛函數(shù)各自塞進(jìn)去而是塞一個(gè)指針不同實(shí)現(xiàn)可能不同常見(jiàn)實(shí)現(xiàn)是每個(gè)類一張?zhí)摫砻總€(gè)對(duì)象一個(gè)指向虛表的指針。所以一個(gè)只有虛函數(shù)、沒(méi)有數(shù)據(jù)成員的類在 64 位平臺(tái)上通常是 8 字節(jié)。首次聽(tīng)到這個(gè)結(jié)論的人常常誤以為是數(shù)虛函數(shù)的個(gè)數(shù)那是誤解。4.2 訪問(wèn)控制不影響內(nèi)存布局public、private、protected只是編譯期的檢查運(yùn)行時(shí)的內(nèi)存布局里沒(méi)有任何標(biāo)記。編譯器不會(huì)因?yàn)槌蓡T是私有就給它加密也不會(huì)改變排列順序。class Same1 { public: int x; int y; }; class Same2 { private: int x; int y; };這兩個(gè)類的大小和布局完全一樣。這意味著如果你通過(guò)某種手段繞過(guò)訪問(wèn)控制比如reinterpret_cast到相同布局的結(jié)構(gòu)體是可以直接讀寫私有成員的。這種做法非常危險(xiǎn)因?yàn)榫幾g器是允許重新排列不同訪問(wèn)段成員的標(biāo)準(zhǔn)里也沒(méi)保證私有成員一定放在公有成員之后一旦換編譯器或者改代碼布局就可能變化直接崩潰。我在實(shí)際項(xiàng)目里遇到過(guò)類似的事有人為了和某個(gè)外部二進(jìn)制格式對(duì)齊用reinterpret_cast把對(duì)象直接寫到文件里線上跑著還挺穩(wěn)。后來(lái)加了一個(gè)私有成員前面所有字段全部錯(cuò)位讀出來(lái)的數(shù)據(jù)全亂了。教訓(xùn)是跨邊界傳遞對(duì)象必須顯式序列化每一個(gè)字段不能依賴內(nèi)存布局。這條經(jīng)驗(yàn)我在幾個(gè)項(xiàng)目里反復(fù)見(jiàn)到被違反最后都免不了重構(gòu)。4.3 單繼承下的布局與基類子對(duì)象的位置單繼承時(shí)基類的子對(duì)象通常放在派生類對(duì)象的起始位置。所以把派生類對(duì)象的地址轉(zhuǎn)換成基類指針偏移量一般是零class Base { int a; }; class Derived : public Base { int b; };Derived的對(duì)象布局是 Base 子對(duì)象在前b在后。Base* p d;不需要做任何地址調(diào)整。這個(gè)規(guī)則看似天經(jīng)地義其實(shí)有前提單繼承、非虛繼承。多繼承時(shí)第二個(gè)及以后的基類子對(duì)象會(huì)有非零偏移指針轉(zhuǎn)換需要調(diào)整地址這就引出了著名的多重繼承指針值不同的現(xiàn)象。我見(jiàn)過(guò)很多人調(diào)試時(shí)打印指針地址發(fā)現(xiàn)基類指針和派生類指針的值不一樣懷疑類型轉(zhuǎn)換出錯(cuò)。實(shí)際上這是標(biāo)準(zhǔn)允許的轉(zhuǎn)換本身是對(duì)的關(guān)鍵在于子對(duì)象在內(nèi)存里的位置不同。如果拿這個(gè)指針去做哈?；蛘弑容^很容易出 bug必須統(tǒng)一類型后再比較。4.4 虛函數(shù)帶來(lái)的模型變化一旦類里有虛函數(shù)對(duì)象模型就多了一層間接。常見(jiàn)的實(shí)現(xiàn)方式是每個(gè)有虛函數(shù)的類生成一張?zhí)摵瘮?shù)表每個(gè)對(duì)象內(nèi)部放一個(gè)指向這張表的指針一般放在對(duì)象起始位置。這樣調(diào)用虛函數(shù)時(shí)先通過(guò)對(duì)象的指針找到虛表再按固定位置取出函數(shù)地址實(shí)現(xiàn)運(yùn)行時(shí)多態(tài)。影響有三點(diǎn)值得注意。第一對(duì)象大小會(huì)增加常見(jiàn)的 64 位平臺(tái)上是 8 字節(jié)和虛函數(shù)個(gè)數(shù)無(wú)關(guān)。第二對(duì)象的前幾個(gè)字節(jié)不是你的成員數(shù)據(jù)如果依賴內(nèi)存布局去讀對(duì)象必須把這個(gè)指針?biāo)氵M(jìn)去。第三構(gòu)造和析構(gòu)期間虛表指針會(huì)發(fā)生變化所以構(gòu)造函數(shù)和析構(gòu)函數(shù)里調(diào)用虛函數(shù)不會(huì)表現(xiàn)出多態(tài)行為——這個(gè)坑我在帶新人的時(shí)候幾乎每個(gè)季度都要講一次。class Base { public: Base() { init(); } // 調(diào)的是 Base::init virtual void init() { /* ... */ } }; class Derived : public Base { public: void init() override { /* ... */ } // 構(gòu)造 Base 期間不會(huì)調(diào)到這 };原因很直接構(gòu)造基類子對(duì)象的時(shí)候派生類部分還沒(méi)構(gòu)造完對(duì)象此時(shí)就是基類對(duì)象虛表指針指向基類的表自然調(diào)用基類版本。這不是設(shè)計(jì)缺陷是語(yǔ)言為了保證類型安全做出的規(guī)定。5. this 指針每個(gè)非靜態(tài)成員函數(shù)背后的隱形參數(shù)5.1 this 不是對(duì)象里的字段而是函數(shù)的一個(gè)隱藏參數(shù)這是關(guān)于 this 最常見(jiàn)的誤解必須先糾正。this 不是對(duì)象內(nèi)存里的一個(gè)成員它不占對(duì)象大小也不會(huì)出現(xiàn)在布局里。它本質(zhì)上是編譯器給每個(gè)非靜態(tài)成員函數(shù)偷偷添加的第一個(gè)參數(shù)。class Acc { int val 0; public: void set(int v) { val v; } }; Acc a; a.set(5);在編譯器眼里大致等價(jià)于struct Acc { int val; }; void Acc_set(Acc* self, int v) { self-val v; } Acc_set(a, 5);函數(shù)體里寫val編譯器自動(dòng)翻譯成self-val。這個(gè)self就是 this。所以 this 的生命周期和函數(shù)調(diào)用一致函數(shù)進(jìn)來(lái)它就有了函數(shù)返回它就失效了存下來(lái)也不好使。至于它具體放在哪里標(biāo)準(zhǔn)沒(méi)有規(guī)定。常見(jiàn)的實(shí)現(xiàn)是放在寄存器里有些平臺(tái)參數(shù)多的時(shí)候可能壓棧。所以this 在棧上或者this 在堆上這類說(shuō)法都是錯(cuò)的——它只是函數(shù)調(diào)用的一部分不構(gòu)成對(duì)象的一部分。5.2 const 成員函數(shù)改的是 this 的類型理解 this 的類型const成員函數(shù)的行為就變得順理成章。在非 const 成員函數(shù)里this 的類型是ClassName* const——指向?qū)ο蟮闹羔槺旧聿豢勺儾荒茏屗赶騽e處但指向的內(nèi)容可以改。所以你能修改成員變量。在 const 成員函數(shù)里this 的類型變成const ClassName* const——既不能指向別處也不能修改所指內(nèi)容。所以編譯器禁止你修改任何非 mutable 成員。這不是什么特殊魔法就是一層的 const 限定。class Store { int data 0; mutable int hits 0; public: int get() const { hits; // 合法mutable // data; // 編譯錯(cuò)誤const 對(duì)象 return data; } };mutable的用途是標(biāo)記邏輯上不改變對(duì)象狀態(tài)的成員比如緩存計(jì)數(shù)、懶加載的緩存值、調(diào)試用的訪問(wèn)次數(shù)。但用多了會(huì)破壞 const 的語(yǔ)義我一般限制在性能優(yōu)化場(chǎng)景業(yè)務(wù)字段絕不加?；?this 的 const 差異還能實(shí)現(xiàn) const 與非 const 版本的重載class Box { int v 0; public: int at() { return v; } const int at() const { return v; } };非 const 對(duì)象調(diào)用非 const 版本拿到可寫引用const 對(duì)象只能拿到 const 引用從編譯期就堵住了越權(quán)修改。這是 C 容器普遍采用的模式寫自己的類時(shí)照著做接口的一致性會(huì)好很多。5.3 空指針調(diào)用成員函數(shù)到底會(huì)發(fā)生什么這是面試和實(shí)戰(zhàn)里都很經(jīng)典的問(wèn)題?？创aclass Ghost { int secret 1; public: void hello() { /* 不訪問(wèn)任何成員 */ } int reveal() { return secret; } }; Ghost* g nullptr; g-hello(); // 很多平臺(tái)上不崩潰 g-reveal(); // 大概率崩潰為什么hello()不崩潰因?yàn)榫幾g后它就是一個(gè)普通函數(shù)參數(shù)傳進(jìn)去是 nullptr函數(shù)體里沒(méi)有解引用自然沒(méi)毛病。而reveal()要讀secret等價(jià)于self-secretself是空指針讀取地址接近 0 的內(nèi)存通常觸發(fā)訪問(wèn)違例。但這絕不意味著空指針調(diào)成員函數(shù)是安全的。這是未定義行為標(biāo)準(zhǔn)層面沒(méi)有任何保證。編譯器完全可以在函數(shù)體開頭插入對(duì) this 的空檢查或者因?yàn)閮?yōu)化把不會(huì)為空的指針當(dāng)作前提從而刪除后面的空判斷。我實(shí)際遇到過(guò)同一段代碼在調(diào)試構(gòu)建下跑得好好的開了優(yōu)化就崩排查了半天才發(fā)現(xiàn)是某個(gè)回調(diào)里對(duì)象已經(jīng)銷毀但指針沒(méi)清。真正穩(wěn)妥的做法只有兩條一是成員函數(shù)里操作成員之前確保對(duì)象存活二是對(duì)于可能為空的對(duì)象指針調(diào)用前顯式判斷。指望只調(diào)用不訪問(wèn)成員的函數(shù)來(lái)規(guī)避崩潰是在賭編譯器行為不值得。5.4 返回 *this 與鏈?zhǔn)秸{(diào)用this 最實(shí)用的場(chǎng)景之一就是讓多個(gè)操作串成一句。原理很簡(jiǎn)單成員函數(shù)返回*this的引用下一個(gè)調(diào)用就作用在同一個(gè)對(duì)象上。class Builder { std::string buf; public: Builder append(const std::string s) { buf s; return *this; } Builder wrap(const std::string l, const std::string r) { buf l buf r; return *this; } const std::string get() const { return buf; } }; std::string r Builder{}.append(hello).wrap([, ]).get();返回引用而不是值是為了讓鏈?zhǔn)秸{(diào)用作用在同一個(gè)對(duì)象上同時(shí)也是為了避免無(wú)謂的拷貝。如果返回Builder值每次鏈?zhǔn)秸{(diào)用都在操作臨時(shí)副本最終結(jié)果就丟了。如果返回指針調(diào)用方還得寫箭頭可讀性差。有個(gè)細(xì)節(jié)要注意返回*this的引用前提是對(duì)象在調(diào)用鏈期間一直存活。如果這個(gè)對(duì)象是棧上的臨時(shí)對(duì)象把它返回出去就是懸空引用那就踩到生命周期問(wèn)題上了。我的習(xí)慣是這類鏈?zhǔn)椒椒ㄖ挥糜诰植繕?gòu)造不跨越函數(shù)邊界傳遞。5.5 靜態(tài)成員函數(shù)為什么沒(méi)有 this靜態(tài)成員函數(shù)屬于類本身不屬于任何對(duì)象它被調(diào)用時(shí)沒(méi)有具體的對(duì)象自然就沒(méi)有 this。這也導(dǎo)致靜態(tài)成員函數(shù)里不能直接訪問(wèn)非靜態(tài)成員——編譯器找不到self。class Util { int x 0; public: static void reset(Util obj) { // x 0; // 錯(cuò)誤沒(méi)有 this obj.x 0; // 顯式傳對(duì)象才行 } };實(shí)踐中靜態(tài)成員函數(shù)常被用來(lái)做工廠函數(shù)、工具函數(shù)、與類相關(guān)的全局邏輯。它和普通函數(shù)相比只多了個(gè)作用域歸屬調(diào)用時(shí)不用傳對(duì)象也正因?yàn)槿绱怂荒鼙宦暶鳛?const——const 是給 this 加限制的沒(méi)有 this也就沒(méi)有 const 的意義。還有一點(diǎn)容易忽略靜態(tài)成員函數(shù)可以被取地址成普通函數(shù)指針因?yàn)樗恍枰壎▽?duì)象。非靜態(tài)成員函數(shù)取地址得到的不是普通函數(shù)指針要調(diào)用還得配一個(gè)對(duì)象這是類型擦除和回調(diào)注冊(cè)時(shí)經(jīng)?？ㄗ〉牡胤健?. 常見(jiàn)問(wèn)題排查表與幾條實(shí)操心法6.1 高頻報(bào)錯(cuò)速查把我在帶人過(guò)程中反復(fù)見(jiàn)到的現(xiàn)象整理成一張表遇到時(shí)可以按圖索驥現(xiàn)象常見(jiàn)原因處理方式編譯報(bào)不是類型名或未聲明名字在當(dāng)前聲明點(diǎn)尚未可見(jiàn)調(diào)整聲明順序或改用尾置返回類型類外定義返回嵌套類型報(bào)錯(cuò)返回類型不在類作用域內(nèi)寫成Class::Type或尾置返回類型sizeof比成員之和預(yù)期大內(nèi)存對(duì)齊填充按類型大小重排成員從大到小空類sizeof不是 0對(duì)象地址唯一性要求正?，F(xiàn)象無(wú)需處理派生類里調(diào)不到基類同名函數(shù)派生類名字隱藏加using Base::func;或顯式限定靜態(tài)成員變量鏈接錯(cuò)誤只聲明未定義類外補(bǔ)定義或使用內(nèi)聯(lián)靜態(tài)成員const 對(duì)象調(diào)成員函數(shù)報(bào)錯(cuò)缺少 const 版本成對(duì)提供 const 與非 const 重載構(gòu)造函數(shù)里調(diào)虛函數(shù)沒(méi)走派生版本構(gòu)造期間虛表尚未切換把初始化邏輯移到專門的 init 方法優(yōu)化后運(yùn)行崩潰調(diào)試版正?？罩羔樥{(diào)成員函數(shù)未定義行為確保對(duì)象存活調(diào)用前判空派生類指針轉(zhuǎn)換后地址變了多重繼承子對(duì)象偏移統(tǒng)一類型再比較或哈希6.2 我自己堅(jiān)持的幾條實(shí)踐原則第一條也是最重要的一條涉及對(duì)象布局的地方一律不靠猜。只要是sizeof、偏移、序列化、跨進(jìn)程共享內(nèi)存這類場(chǎng)景我都會(huì)寫一段最小編譯單元把sizeof和offsetof打印出來(lái)驗(yàn)證而不是照著記憶算。不同平臺(tái)、不同編譯選項(xiàng)、不同對(duì)齊設(shè)置都會(huì)導(dǎo)致結(jié)果不同憑經(jīng)驗(yàn)算十次有八次是對(duì)的剩下兩次就是線上事故。第二條成員函數(shù)返回嵌套類型時(shí)優(yōu)先用尾置返回類型。這個(gè)習(xí)慣讓我省掉了大量Class::Type的重復(fù)書寫也讓簽名在代碼格式化之后依然清晰。有人覺(jué)得auto f() - T不直觀但只要項(xiàng)目統(tǒng)一讀起來(lái)是沒(méi)障礙的。第三條this相關(guān)的代碼盡量寫顯式。比如鏈?zhǔn)秸{(diào)用返回*this時(shí)方法名以動(dòng)詞開頭明確表示這是一個(gè)會(huì)修改對(duì)象狀態(tài)的操作只讀方法一律加 const讓編譯器幫我判斷誰(shuí)在越權(quán)修改。我合作過(guò)的一個(gè)團(tuán)隊(duì)有過(guò)硬性規(guī)定所有不修改成員狀態(tài)的成員函數(shù)必須加 const否則代碼評(píng)審不過(guò)。堅(jiān)持一年下來(lái)很多邏輯錯(cuò)誤在編譯期就被攔住了。第四條對(duì)象大小變化要當(dāng)成一次接口變更對(duì)待。一旦某個(gè)類被放進(jìn)容器、內(nèi)存池或者共享內(nèi)存改動(dòng)它的成員布局可能引發(fā)難以發(fā)現(xiàn)的越界寫入。我的做法是在類旁邊加一個(gè)靜態(tài)斷言把預(yù)期的大小寫死class Rec { int id; int flags; }; static_assert(sizeof(Rec) 8, layout changed, check serialization);這條斷言在 CI 上跑一旦布局變化立刻報(bào)警逼著改的人去檢查所有相關(guān)的讀寫代碼?？此贫鄬懸恍袑?shí)際上擋掉過(guò)好幾次隱蔽的數(shù)據(jù)錯(cuò)位問(wèn)題。還有一條關(guān)于學(xué)習(xí)路徑的體會(huì)。這四個(gè)概念單拎出來(lái)都不難難的是把它們串起來(lái)用。我建議的復(fù)盤方式是隨便找一段自己寫過(guò)的類從編譯器眼中它長(zhǎng)什么樣開始手動(dòng)畫出它的內(nèi)存布局標(biāo)出每個(gè)函數(shù)編譯后的簽名標(biāo)出每個(gè)this的類型再看 const 在哪里起作用、名字在哪個(gè)作用域被找到。這樣過(guò)一遍比把教材翻三遍有用得多。等到下一次再看到莫名其妙的報(bào)錯(cuò)你腦子里浮現(xiàn)的就不是語(yǔ)法怎么寫的而是編譯器處理到哪一步、在哪個(gè)作用域查找、手里拿的是哪個(gè)地址。