學習C有些年頭的人多少都聽過這樣一句話C不僅僅是一門語言它是一塊由多種子語言拼合而成的聯(lián)邦。而《Effective C》第一章的標題“讓自己習慣C”恰恰點明了最關(guān)鍵的一件事——讀這本書之前你先得把腦袋里的“語法知識”切換成“工程思維”。第一章不講深奧的模板元編程不碰復(fù)雜的并發(fā)模型它只教你四件最小但最容易被忽略的事如何看待C、如何定義常量、如何用好const、如何保證對象在使用前完成初始化。這章篇幅不多含金量卻極高。我當年剛讀的時候覺得自己全會了等真正寫在生產(chǎn)環(huán)境里跑了半年發(fā)現(xiàn)當時犯下的低級問題十條里有七條都能在這章里找到答案。這篇文章就圍繞這四件事展開結(jié)合我實際項目里踩過的坑把第一章的精華掰開揉碎講清楚。如果你剛學完語法或者寫了一段C但總覺得代碼黏黏糊糊不對勁這篇值得認真看。1. 語言聯(lián)邦先看清C的四副面孔1.1 為什么非要把C拆成四個部分很多新手學C最大的困惑是為什么同一件事有那么多不同的寫法傳參可以用指針、可以用引用、可以用智能指針循環(huán)可以用下標、可以用迭代器、可以用范圍for甚至定義一個常量都至少有三種看似等價的方式。這不是C故意刁難你而是因為C本來就是多重范式的語言它同時承載著四種完全不同的編程思路。這本書第一章的第一個條款就把C拆成了四個子語言這是我見過最精準的概括C語言。C以C為基礎(chǔ)區(qū)塊、語句、預(yù)處理器、內(nèi)置數(shù)據(jù)類型、數(shù)組、指針通通來自C。這一層沒有類沒有模板沒有異常只有“照C的方式寫”的樸素規(guī)則。面向?qū)ο驝。類、封裝、繼承、多態(tài)、虛函數(shù)、動態(tài)綁定這一層是C作為面向?qū)ο笳Z言的靈魂。誰該負責什么、接口怎么設(shè)計、對象之間怎么協(xié)作都歸這一層管。模板C。模板元編程讓C獲得了編譯期計算的威力它把“編程”這件事從運行期搬到編譯期。這一層的思維方式和前兩層截然不同——你不是在寫代碼而是在設(shè)計讓編譯器替你生成代碼的規(guī)則。STL。標準模板庫是模板C最成功的應(yīng)用但它有自己專屬的規(guī)約容器、迭代器、算法、函數(shù)對象怎么配合都遵循一套完全不同于C風格的原則。1.2 用統(tǒng)一思維寫C早晚出事這個拆分的價值不在于“知道有四種”而在于“針對不同區(qū)域用不同的策略”。我見過不少寫了好幾年C的人遇到任何對象一律用值傳遞理由是“C傳參就是復(fù)制”碰見任何容器都下意識想用下標訪問理由是“數(shù)組都這么用”——這些思維放到對應(yīng)的子語言里沒錯但跨區(qū)域套用就翻車。舉個具體的例子。在某公司的一次代碼評審里有人在一個模板函數(shù)里寫了if (a b)來比較兩個自定義類型。看起來很正常對不對但那個類型是給STL排序算法用的只實現(xiàn)了operator的嚴格弱序版本卻沒有實現(xiàn)全局的operator導(dǎo)致編譯直接卡死。這就是典型C語言思維混進模板C區(qū)域的結(jié)果。正確做法是在模板區(qū)盡量依賴標準算法的約定用std::less這類工具而不是自己拍腦袋寫比較邏輯。認清語言聯(lián)邦之后后面三條條款就好理解了——它們本質(zhì)上都是“在當前區(qū)域選擇最合適的表達方式”而不是“C只能這么寫”。這也是第一章為什么把這條放在最前面。不建立這個頂層認知后面學const、學初始化都只是記了個零散知識點過三個月照樣忘。2. 以編譯器替換預(yù)處理器少用#define的理由不止一個2.1 宏定義的三宗罪類型檢查、作用域、調(diào)試符號條款2的標題是“盡量以 const、enum、inline 替換 #define”核心主張是凡是能用編譯器做的事就不要甩給預(yù)處理器。#define ASPECT_RATIO 1.653這種寫法在C時代是標準做法但拿到C里就有三個實打?qū)嵉穆闊５谝缓隂]有類型檢查。1.653在預(yù)處理階段就是一個赤裸裸的字符替換編譯器根本不知道它是一個double。萬一某處代碼把這個宏誤當成整數(shù)用編譯器不會給出任何警告——因為它壓根沒機會看到ASPECT_RATIO這個符號它只看到字面量。而如果你寫成const double AspectRatio 1.653;編譯器就會幫你盯住類型。這種差異在大型項目里直接決定了某些bug是編譯期暴露還是上線后爆炸。第二宏的作用域是全局的。你沒法聲明一個“只在某個類里有效的#define”預(yù)處理階段壓根不存在類這個概念。你想讓某個常量只屬于某個類宏做不到。這是它和const之間最本質(zhì)的差距。第三宏不會出現(xiàn)在符號表里。用宏定義常量調(diào)試器除了1.653這個裸數(shù)字什么都看不到。你斷點里檢查一個名叫ASPECT_RATIO的變量結(jié)果調(diào)試器告訴你不存在這個符號——因為它在編譯前就已經(jīng)被替換沒了。就為這一個原因我身邊所有資深同事都清一色地禁止在代碼里用宏定義數(shù)值常量。2.2 專屬常量的正解static成員與enum hack如果你想在類內(nèi)部定義一個常量卻有多個不同對象都用到它直接寫const double AspectRatio 1.653;放在頭文件里也行但如果這個常量只屬于類自身C的標準做法是聲明為類的static const成員。聲明寫在類內(nèi)定義寫在實現(xiàn)文件里像這樣class GameConfig { private: static const int MaxPlayers 8; // 聲明并在聲明處給初值 }; // 實現(xiàn)文件里補一個定義以防某些編譯期需要地址 const int GameConfig::MaxPlayers;這種寫法比宏干凈得多類型安全、作用域被限定在類內(nèi)、可以用于類內(nèi)常量表達式。但有一個情況需要補一個技巧如果你的編譯器版本較老還不支持類內(nèi)給static const成員直接初始化或者你想用它來定義數(shù)組大小但標準不允許這時候就該上“enum hack”了。enum hack的做法是在類內(nèi)聲明一個枚舉把常量值塞進枚舉里class GameConfig { private: enum { MaxPlayers 8 }; // 舊編譯器也能過且不會占用對象空間 };它看起來像變通實際意義卻不小。枚舉常量是編譯期純右值絕不會被意外取地址也不會有鏈接問題——這在老項目里是非常值錢的特性。即使今天C17都普及了這套寫法在底層庫的代碼里依然隨處可見。遇到舊版編譯環(huán)境或者對代碼體積有極端要求的場景enum hack仍是第一選擇。2.3 inline函數(shù)如何替代宏函數(shù)比常量宏更危險的是宏函數(shù)。經(jīng)典的坑是寫一個求最大值的宏#define MAX(a, b) ((a) (b) ? (a) : (b))看起來加了足夠多的括號已經(jīng)嚴絲合縫了但宏的本質(zhì)是文本替換它不會只執(zhí)行一次。假設(shè)你調(diào)用MAX(i, j)在預(yù)處理之后i可能被求值兩次一次在條件判斷里一次在返回表達式里。結(jié)果i被累加了兩次而你完全不知道。這種bug極其隱蔽它在單元測試里可能連續(xù)跑幾十次都不觸發(fā)但一旦實際調(diào)用順序踩中就各種莫名其妙的狀態(tài)錯亂。替換宏函數(shù)的正解是模板加inline。模板保證類型安全inline消除函數(shù)調(diào)用開銷且表達式只被求值一次templatetypename T inline T Max(const T a, const T b) { return a b ? a : b; }再執(zhí)行Max(i, j)i只作為參數(shù)求值一次行為完全符合直覺。我以前在某個項目里接手過一片用宏寫工具函數(shù)的代碼光是把一個#define SAFE_DELETE(p) ...替換成模板函數(shù)就修掉了三個隱藏bug。從那以后我在團隊里的規(guī)矩就一句話新代碼一律禁止宏函數(shù)用const、enum、inline解決。3. 盡可能使用const比你想的更值錢3.1 它定義了“誰能改”也定義了“誰能看”條款3講的是const這大概是第一章里最實用、也最容易被低估的一條。很多初學者對const的理解只停留在“用const修飾變量后不能修改”但const在C里的覆蓋面遠比這寬。它不僅能修改變量的可變性還能修飾指針本身、修飾指針指向的數(shù)據(jù)修飾成員函數(shù)的調(diào)用者是誰。先看指針這一層。同樣是const放在不同位置語義完全不同const char* p abc; // 指向的數(shù)據(jù)不可改指針本身可改 char* const q abc; // 指向的數(shù)據(jù)可改指針本身不可改 const char* const r abc; // 數(shù)據(jù)和指針都不可改很多人背過這個區(qū)別但實際寫代碼時經(jīng)常分不清該用哪個。我的建議很簡單默認情況下凡是傳入函數(shù)且不打算修改的字符指針一律寫成const char*這樣調(diào)用方看到簽名就知道“這個函數(shù)不會動我的數(shù)據(jù)”凡是表示容器或?qū)ο蟊旧怼⑶也辉试S重新指向的才考慮const修飾指針本身。這套規(guī)則不復(fù)雜卻能極大地提升代碼的自文檔化程度。迭代器和指針很像但有個容易弄反的地方。對STL容器來說const iterator表示這個迭代器本身不能移動但它指向的元素卻是可改的真正表示“指向的元素不能改”的是const_iterator。換句話說如果你希望遍歷時不動容器里的元素就該用const_iterator而不是把迭代器本身聲明為const。代碼里這種一字母之差就是順手Bug和穩(wěn)健代碼之間的距離。3.2 const成員函數(shù)重載與邏輯常性的權(quán)衡const對成員函數(shù)的價值得從一個常對象說起。假設(shè)你寫了一個類內(nèi)部有一段計算邏輯需要讀取成員變量但保證不會修改對象狀態(tài)。你能不能在一個const對象上調(diào)用這個函數(shù)答案是只有當這個成員函數(shù)被聲明為const時編譯器才允許你調(diào)用。這背后是C的底層規(guī)則const對象只能調(diào)用const成員函數(shù)。由此引出一個很實用的編程模式——const版本和非const版本的重載。比如訪問一個矩陣類的某個元素const T operator()(size_t row, size_t col) const { return data[row * cols col]; } T operator()(size_t row, size_t col) { return data[row * cols col]; }常對象調(diào)用時只能走const版本因此返回的是const引用外部無法篡改數(shù)據(jù)普通對象調(diào)用走非const版本可以自由修改。這兩個函數(shù)簽名只差一個const卻讓同一個類在“只讀”和“可寫”兩種語境下都安全。反過來如果你只寫一個非const版本那常對象就完全沒法訪問這個接口——這不是功能缺失的問題而是類型的語義被破壞了。還有一件和const成員函數(shù)相關(guān)的經(jīng)典事mutable。它允許在const成員函數(shù)里修改某些成員變量適用于緩存、計數(shù)這類“邏輯上不影響對象可見狀態(tài)”的字段。但我要提醒一句mutable是一把雙刃劍。我見過有人為了圖省事把一個業(yè)務(wù)核心字段標成mutable然后在const成員函數(shù)里偷偷改了它的值導(dǎo)致后續(xù)全是并發(fā)問題。正確的態(tài)度是mutable只能給那些“改了也看不出來”的成員用比如緩存值、調(diào)試計數(shù)業(yè)務(wù)數(shù)據(jù)絕不應(yīng)當因為迫不得已而標記mutable。3.3 實戰(zhàn)心得const一寫到底的收益我在實際項目里最深的體會是const的價值不在單個變量上而在它構(gòu)建起來的“類型契約”里。一個函數(shù)聲明成const std::string getName() const你立刻就知道它不會修改對象、它返回的東西也不能通過這個引用去修改。這一眼能得出的結(jié)論比任何注釋都可靠。反過來說如果你寫的函數(shù)明明不修改對象卻忘了加const后果同樣嚴重調(diào)用方持有const引用時根本沒法調(diào)用你的函數(shù)。這種情況在大型重構(gòu)里尤為常見——原來沒有const的代碼引用得到處都是你去加一個const成員函數(shù)編譯器會指出所有漏加const的調(diào)用點一個都不放過。那次我重構(gòu)一個內(nèi)部庫改完編譯器報了一百多個錯誤全是“不能在const對象上調(diào)用非const函數(shù)”。雖然改得頭大但這恰恰說明const在保護你它讓那些無意中被修改對象狀態(tài)的地方全部無所遁形。const還有一個經(jīng)常被忽略的應(yīng)用場景函數(shù)返回值。返回一個大對象時返回const引用可以避免不必要的復(fù)制如果這個返回值只允許讀取const更是在接口層面鎖死了語義。把const當成一種API設(shè)計工具而不是一個語法裝飾這才算真正“用”好了它。4. 確定對象使用前已先被初始化看不見的變量最危險4.1 初始化和賦值的區(qū)別比你想的大得多條款4的標題很直白“確定對象使用前已先被初始化”。這句聽起來像廢話實際卻是C里最容易翻車的領(lǐng)域。原因是C對“未初始化變量”的態(tài)度極為寬松它允許你定義一個局部變量而不賦初值然后編譯器只是給出一個警告甚至警告都不給。這個變量里存的是那塊棧內(nèi)存上殘留的舊數(shù)據(jù)可能是任何值。我印象最深的是一次線上事故。某個服務(wù)在某種特殊輸入下會計算出一個異常的溫度值排查了一整天才發(fā)現(xiàn)罪魁禍首是一個連初始化都沒有的結(jié)構(gòu)體成員——它在某個極罕見的路徑里被當作有效值參與計算了。寫代碼的人不是故意的只是覺得“反正后面會賦值”結(jié)果漏了一條路徑。這正是條款4想杜絕的事C不會替你初始化內(nèi)置類型一切都要你自己來。這里必須先厘清兩組概念。第一組是“初始化和賦值”。初始化發(fā)生在構(gòu)造函數(shù)里是給對象首次設(shè)置初值賦值是對象已經(jīng)存在后再修改它。雖然從最終效果看兩者殊途同歸但成本完全不同。初始化調(diào)用的是拷貝構(gòu)造賦值走的是“構(gòu)造臨時對象拷貝賦值”多了一次多余的操作。更重要的是有些成員比如const成員和引用成員壓根不允許賦值只能在初始化列表里賦值。因此規(guī)則非常簡單所有成員一律在初始化列表里初始化不要在構(gòu)造函數(shù)體內(nèi)賦值。4.2 初始化列表的正確姿勢與初始化順序陷阱構(gòu)造函數(shù)初始化列表的另一個好處是直觀。一個類如果有十個成員全寫在初始化列表里讀者一眼能看出每個成員的初值來源如果寫在函數(shù)體里得心里默認走一遍“先構(gòu)造默認值、再賦值”的過程可讀性差一截。還有個細節(jié)成員聲明的順序決定初始化順序而初始化順序和你在初始化列表里寫的前后位置無關(guān)。也就是說如果你在初始化列表里先寫成員B再寫成員A但類定義里A聲明在B之前編譯器依然會老老實實先初始化A再初始化B。如果你讓某個成員的初始化依賴另一個成員的值就必須保證被依賴的成員在類定義里先聲明。我在這上面栽過一次。有個配置類內(nèi)部有個logger_成員和log_level_成員我在初始化列表里先寫了logger_(log_level_)再寫了log_level_(INFO)結(jié)果運行時loger拿到的是零值。查了半天原因正是類定義里 log_level_ 聲明在 logger_ 之后初始化時 logger_ 先去讀一個還沒被初始化完畢的 log_level_。從那之后我定了一條死規(guī)矩初始化列表的順序必須和成員聲明順序完全一致哪怕編譯器不報錯也要保持一致因為這是唯一能讓自己避免意外的辦法。4.3 跨編譯單元的靜態(tài)對象初始化最隱蔽的雷比成員初始化順序更坑的是“跨編譯單元的靜態(tài)對象初始化順序”。假設(shè)有兩個源文件分別定義了各自的文件級靜態(tài)對象A和B其中A的構(gòu)造函數(shù)需要用到B的數(shù)據(jù)。C標準并沒有明確規(guī)定這兩個靜態(tài)對象在不同編譯單元之間的初始化順序。也就是說你的程序在某些編譯器上能正常跑換一個編譯器或者換一個鏈接順序A的構(gòu)造函數(shù)可能先于B執(zhí)行然后A讀到一堆垃圾數(shù)據(jù)。這個問題的標準對策叫“以local static對象替換non-local static對象”——把靜態(tài)對象放進一個函數(shù)里函數(shù)第一次被調(diào)用時完成初始化class Config { ... }; Config getConfig() { static Config instance; // 函數(shù)內(nèi)的local static第一次調(diào)用時才初始化 return instance; }函數(shù)內(nèi)的local static對象C標準保證了它在控制流第一次經(jīng)過其聲明時被初始化之后所有調(diào)用都復(fù)用同一份實例。這種模式還有個名字叫Meyers Singleton用起來極其順手。多個模塊如果都要訪問同一個配置實例就都去調(diào)用getConfig()哪個模塊先調(diào)用哪個模塊就先觸發(fā)初始化順序完全由運行時決定再也不會和“源文件編譯順序”之類的事情糾纏。我之前重構(gòu)過一個模塊把原來散落在好幾個文件里的文件級靜態(tài)對象全部收進這樣的訪問函數(shù)里一個懸了很久的隨機崩潰就這樣消失了。4.4 手工逐項初始化沒有捷徑可走C里還有一種一不小心就漏掉的初始化發(fā)生在構(gòu)造函數(shù)之外的普通函數(shù)里。比如struct作為局部變量聲明后如果你不做任何初始操作一些成員就是隨機值。C語言里有人用memset(s, 0, sizeof(s))C里這做法危險得多因為非POD類型的內(nèi)存“清零”后對象內(nèi)部的虛表指針或者自建結(jié)構(gòu)可能處于非法狀態(tài)。唯一安全的路子是逐項顯式初始化或者寫一個無參構(gòu)造函數(shù)把所有成員都設(shè)成合理的默認值。寫類的時候我習慣給每個類都寫構(gòu)造函數(shù)哪怕所有參數(shù)都有默認值。原因很樸素只要你不寫構(gòu)造函數(shù)編譯器在某些條件下會生成默認構(gòu)造但那只是“值初始化”或“不初始化”的分岔路。手動寫了構(gòu)造函數(shù)之后你自己才知道到底哪些成員被初始化到了什么值而不是靠運氣。選擇一個無參的、把每個成員都顯式初始化的構(gòu)造函數(shù)對排錯來說是一件大善事——它保證了你創(chuàng)建的每個對象都處于一份確定的狀態(tài)。5. 常見問題與排查技巧實錄5.1 宏替換導(dǎo)致的“幽靈”副作用前面提到的MAX(i, j)宏求值兩次問題實際排查時比想象中更難。因為出錯現(xiàn)場往往不在宏調(diào)用那行而在更后面的邏輯里——一個看似無關(guān)的變量i變得異常大。找到根因的方法只有一個用-E讓編譯器輸出預(yù)處理后的完整文件直接查看宏展開后的真實代碼。這里也想建議大家排查類似問題先別急著單步調(diào)試先用預(yù)處理工具把宏的替身顯形幾秒鐘就能定位問題比在調(diào)試器里猜快得多。5.2 const_cast的濫用與正確用法還有一個我反復(fù)強調(diào)的坑是const_cast。它用于去除對象的const屬性但如果一個對象本質(zhì)上就是一個const對象你用const_cast修改它結(jié)果是未定義的程序可能毫無征兆地崩潰。關(guān)于什么時候才能用const_cast只有當你知道某個對象“實際上”不是const只是當初通過某個const引用或指針傳進來時你才能用它去掉那層“紙糊的const”。某次我在舊代碼里看到有人為了“省事”在const成員函數(shù)里用const_cast修改核心成員結(jié)果多線程下面數(shù)據(jù)錯亂最后把這個字段改成mutable、理順邏輯才徹底修復(fù)。從那以后我給團隊立了規(guī)矩禁用對業(yè)務(wù)數(shù)據(jù)使用const_cast必須用mutable——至少mutable是顯式聲明而且語義受限在類內(nèi)部。5.3 初始化遺漏的排查套路排查未初始化變量最有效率的辦法是打開你所用編譯器針對“可能未初始化”的警告選項并當作錯誤處理。不同編譯器的警告開關(guān)不同但核心思路一致讓編譯器從頭到尾幫你盯住“定義之后有沒有經(jīng)過所有路徑賦初值”。把警告全開、全當錯誤處理是成本最低、收益最高的初始化問題防線。我在新項目里甚至直接把這種警告設(shè)成CI的失敗條件只要有人新提交的代碼里有未初始化風險構(gòu)建直接失敗一天能攔住好幾次潛在線上事故。5.4 實戰(zhàn)避坑速查清單常量定義優(yōu)先const類內(nèi)常量用static const或enum函數(shù)邏輯用inline模板全線取代#define?！澳懿桓木筒桓摹钡牡胤饺珜慶onst包括函數(shù)參數(shù)、成員函數(shù)、返回值。初始化列表里成員的書寫順序要和類定義里的聲明順序嚴格一致。跨編譯單元共享的靜態(tài)對象放入函數(shù)內(nèi)以static方式初始化。新代碼里出現(xiàn)const_cast必須加注釋說明“為什么這里是安全的”否則一律不允許合入。編譯時把“未初始化變量”相關(guān)警告開滿并設(shè)置成錯誤級別。如果你能在項目里把這幾條全部執(zhí)行到位第一章的功夫就算到家了。別小看這些習慣它們是最基礎(chǔ)、卻最能從根上降低返工率的東西。我自己在這些條款的幫助下避開了好幾類當年差點折騰幾宿的bug。往后讀到模板、STL、異常處理等更進階的章節(jié)時你會發(fā)現(xiàn)這些基礎(chǔ)習慣始終在背后起著支撐作用。最后說一點個人體會Effective C第一章的意義不在于讓你記住多少語法規(guī)則而在于讓你養(yǎng)成每次寫代碼時都問自己一句“編譯器知道我想干什么嗎”的習慣。把這點想透了你才算真正開始“習慣C”。