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