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