我很久沒翻開那本橘黃色封面的 C 經(jīng)典了但每當身邊有朋友問“C 到底應該怎么學”我總會提起這本書里的第一章節(jié)“讓自己習慣 C”。作為 Effective C 55 個具體做法的開篇這一章只有四個條款卻奠定了整本書的方法論基礎。這些年我見過太多人把 C 當成一門“帶類的 C”來寫結(jié)果代碼越寫越別扭問題越查越深也有人一上來就扎進模板元編程連基本對象生命周期都沒捋清。這篇摘錄想做的就是把第一章的四個條款掰開揉碎結(jié)合我實際工程里的經(jīng)驗講講每一條規(guī)則背后的“為什么”和落地時的注意點。如果你正準備系統(tǒng)地讀 Effective C或者已經(jīng)讀過但覺得某些條款沒吃透這篇文章可以當作一份帶注釋的閱讀筆記。書里每個條款讀起來都很短但每一條都能展開成一篇長文我會盡量用具體代碼和場景把它們講透。1. 航拍視角先認清 C 是一個語言聯(lián)邦而不是一門單一語言1.1 為什么很多人學 C 越學越混亂原書作者在條款 01 里提出了一個非常經(jīng)典的觀點C 不是一門單一語言而是由四個次語言組成的“語言聯(lián)邦”。這四個次語言分別是C、面向?qū)ο蟮?C、模板 C泛型編程、以及 STL。我第一次讀到這個說法時覺得太抽象了但工作幾年后回頭再看這可能是全書最值得反復咀嚼的一句話。很多人覺得 C 難學本質(zhì)上是因為這四個次語言的使用方式、編程范式、慣用法差別太大。用純 C 的思路寫 C你會覺得類、命名空間、異常都是多余的負擔用面向?qū)ο蟮乃悸酚蔡姿袌鼍澳銜X得模板和算法庫與你格格不入反過來如果你一上來就只用模板元編程那一套又會把簡單的業(yè)務邏輯寫得晦澀難懂。問題不在于你選錯了某一個范式而在于你沒有意識到C 允許你在不同場景下切換到不同范式關(guān)鍵是要知道“現(xiàn)在正站在哪塊領土上”。1.2 四個次語言分別對應什么樣的編程策略我在讀這個條款時給自己畫了一張“心智地圖”這幾年一直在用可以分享給你次語言核心特征典型場景你的思考方式C無類、無模板、無異常面向過程底層模塊、嵌入式、系統(tǒng)調(diào)用封裝指針、內(nèi)存布局、結(jié)構(gòu)體、全局函數(shù)面向?qū)ο?C類、封裝、繼承、多態(tài)、虛函數(shù)業(yè)務模型、架構(gòu)分層、接口設計抽象、對象生命周期、接口與實現(xiàn)分離模板 C編譯期計算、類型推導、泛型抽象容器、算法、類型安全的工具庫類型層面的復用、編譯期行為STL容器、迭代器、算法、函數(shù)對象日常數(shù)據(jù)結(jié)構(gòu)和算法使用迭代器、算法復雜度、容器的選擇舉個例子寫嵌入式驅(qū)動時我基本在用次語言 C 的方式結(jié)構(gòu)體、位運算、函數(shù)指針寫一個大型業(yè)務系統(tǒng)時我切換到面向?qū)ο蟮拇握Z言抽象基類、虛函數(shù)、工廠模式寫一個通用緩存組件時我可能大量使用模板和 traits處理一批數(shù)據(jù)時我直接用 STL 的 vector、sort、find_if。規(guī)則很簡單當遵循某一子語言的規(guī)約時你就只在這個子語言的框架內(nèi)思考這樣能顯著降低認知負擔。條款 01 還提醒了一個很實用的點不同次語言的“高效編程守則”不同取決于你用哪種風格編程。比如在傳統(tǒng)的 C 部分值傳遞通常沒問題但在面向?qū)ο蟮?C 里值傳遞意味著拷貝構(gòu)造和析構(gòu)的額外開銷常量引用往往更合適而在模板代碼里你又得考慮引用折疊和完美轉(zhuǎn)發(fā)。很多人寫 C 代碼“哪里都別扭”往往不是因為語法不熟而是因為沒有意識到自己在混合使用多個子語言卻沒有切換對應的策略。1.3 用這個視角重新審視你手頭的代碼讀完這個條款后我做了一次自查把最近一年寫的某個模塊按四個次語言分類發(fā)現(xiàn)真正屬于“面向?qū)ο?C”的代碼只占三成另外三成是 C 風格的實現(xiàn)四成是 STL 和模板的混合。這個分類幫我找到不少壞味道——比如我在 C 風格的模塊里用了 dynamic_cast在泛型代碼里用虛函數(shù)實現(xiàn)多態(tài)這些都屬于“跨領地操作”雖然能編譯通過但設計上確實不夠干凈。條款 01 本身沒有任何代碼示例也不涉及具體語法但它給了你一個判斷標準當你寫某段代碼覺得“別扭”時先問自己四個問題——我在用哪個次語言寫這個次語言的標準做法是什么我是不是把另一個次語言的規(guī)則帶過來了能不能換一種寫法這四個問題我在 Code Review 時也經(jīng)常用來反問別人比直接改代碼有效得多。2. 從預處理時代到編譯器時代const、enum、inline 如何替換 #define2.1 #define 的三個典型隱患條款 02 是“盡量以 const、enum、inline 替換 #define”這一條表面上是說風格實際上是講“不要依賴預處理器做語言本身該做的事”。我剛?cè)胄袝r特別喜歡用宏定義常量用 #define寫小工具函數(shù)用 #define覺得簡單粗暴。后來在項目里吃過虧才明白宏的三大隱患。第一宏不進入符號表出了編譯錯誤你看到的只有數(shù)字。比如你寫了 #define N 42編譯器報錯信息里只顯示 42不會提示你 N 是什么排查起來全靠記憶。第二宏沒有類型檢查。你在一個需要 double 的地方使用了 int 宏常量編譯器不會給出任何警告一旦協(xié)議格式變化或者數(shù)據(jù)類型升級問題就埋在深處。第三宏在預處理階段替換展開后的副作用很難預測尤其是帶參數(shù)的宏比如 #define SQUARE(x) x * x調(diào)用 SQUARE(1 2) 會展開成 1 2 * 1 2結(jié)果出乎所有人意料。2.2 常量替換的具體做法和場景選擇原書給出的替代方案很明確對于常量優(yōu)先用 const 常量替代 #define如果要在 class 內(nèi)定義一個常量且希望它是編譯期整數(shù)常量可以用 enum 來實現(xiàn)“類似宏”的效果對于函數(shù)宏用 inline 函數(shù)替代。先看最常用的 const 場景。假設你需要定義一個全局常量// 原來的寫法 #define MAX_CONNECTIONS 1024 // 替換后的寫法 const int MaxConnections 1024;這里有個容易忽略的細節(jié)當你用 const 定義全局常量時這個常量默認具有內(nèi)部鏈接internal linkage也就是每個編譯單元都有一份獨立的副本。如果你想讓它在多個編譯單元之間共享需要加上 extern// 頭文件 extern const int MaxConnections; // 某個 .cpp 文件 const int MaxConnections 1024;這一點在大型項目里特別重要。我見過好幾個項目頭文件里直接寫 const std::string kAppName xxx;結(jié)果每個包含這個頭文件的編譯單元都實例化了一份 std::string白白增加了二進制體積。用 extern 聲明、在 cpp 中定義是更好的做法。再看 class 內(nèi)的常量。如果常量只在類內(nèi)使用而且你想讓它在類內(nèi)“可見”C11 之前有一種常見寫法class GamePlayer { private: static const int NumTurns 5; // 常量聲明 int scores[NumTurns]; // 用它來聲明數(shù)組 };這種寫法依賴“類內(nèi)初始化器”和“編譯期常量”的結(jié)合。C11 之后static constexpr 更推薦比如 static constexpr int NumTurns 5;語義更明確。但這里有一個“歷史遺留坑”如果你只是聲明了 static const int NumTurns 而沒有在類外定義取它的地址例如 int* p NumTurns;時某些編譯器會報鏈接錯誤因為缺少定義。解決方法是類外補一行 const int GamePlayer::NumTurns;而 enum 不存在這個問題——enum 沒有地址的概念。這就是條款 02 提到的 enum hack當你想在類內(nèi)聲明一個編譯期整數(shù)常量又不想讓它變成可被取地址的對象時enum 是一個非常合適的工具class GamePlayer { private: enum { NumTurns 5 }; int scores[NumTurns]; };enum 的意義在于它既是編譯期常量又有類型約束而且不能被取地址也沒有鏈接問題。在工作中如果你寫的是老代碼風格的項目enum hack 依然能解決實際問題如果你用的是 C17 及以后的標準static constexpr 通常更優(yōu)雅但理解 enum hack 背后的動機依然重要因為它在模板元編程里無處不在。2.3 函數(shù)宏的 inline 替換帶參數(shù)的宏是一門“危險的藝術(shù)”典型的 #define CALL_WITH_MAX(a, b) ((a) (b) ? (a) : (b)) 即使加了括號也可能因為實參自增表達式被多次求值而產(chǎn)生問題。我實際踩過一次傳了一個 map.find() 的返回值宏內(nèi)部把它比較了兩次、取用了三次迭代器狀態(tài)直接亂掉。inline 函數(shù)可以完美解決這個問題。把宏改成普通函數(shù)加 inline 關(guān)鍵字不僅類型安全參數(shù)只求值一次而且行為可預測templatetypename T inline T callWithMax(const T a, const T b) { return a b ? a : b; }注意這個模板版本接受任意類型而且使用 const 引用避免了不必要的拷貝。這一點是宏無法做到的宏沒有類型概念不會幫你做拷貝優(yōu)化也不理解引用語義。在熱路徑上inline 函數(shù)有機會被內(nèi)聯(lián)展開性能上與宏接近但可調(diào)試性和可讀性完勝。我自己的心得是不要試圖“完全消滅宏”而是要弄懂宏能做什么、不能做什么。配置文件里的版本號、條件編譯開關(guān)、以及那些必須依賴預處理指令才能實現(xiàn)的功能宏依然是唯一選擇但凡是“語言層面能表達的東西”優(yōu)先用語言特性。這條邏輯直到今天依然成立。3. const 的多重身份指針、容器、函數(shù)返回值與成員函數(shù)3.1 指針和迭代器上的 const位置決定含義條款 03 的主題是“盡可能使用 const”。這一條看起來簡單實際是 C 里最容易出 bug 的語法點之一尤其是 const 加在指針的哪個位置含義完全不同。char greeting[] hello; char* p greeting; // 非 const 指針非 const 數(shù)據(jù) const char* p2 greeting; // 非 const 指針const 數(shù)據(jù) char* const p3 greeting; // const 指針非 const 數(shù)據(jù) const char* const p4 greeting; // const 指針const 數(shù)據(jù)判斷方法很簡單看 const 修飾的是誰。const 在星號左邊修飾的是“被指向的數(shù)據(jù)”const 在星號右邊修飾的是“指針本身”。這里的“數(shù)據(jù)”到底是字符串還是對象在數(shù)組和指針場景中表現(xiàn)得特別明顯。我經(jīng)常在 Code Review 里看到有人把只讀的字符串參數(shù)寫成 char*結(jié)果旁邊還掛著一堆 const 警告。改成 const char* 或 const std::string函數(shù)體里再也不會有人試圖修改傳入內(nèi)容。STL 迭代器也有同樣的規(guī)則。const_iterator 相當于 const 數(shù)據(jù)的指針它指向的容器元素不能通過該迭代器修改但迭代器本身可以移動而 const 迭代器iterator 對象本身是 const不能移動但指向的元素可以改。前者是“只讀視角”后者是“固定位置”。std::vectorint vec {1, 2, 3}; const std::vectorint::iterator it vec.begin(); // 迭代器本身不能移動 std::vectorint::const_iterator cit vec.begin(); // 指向的元素不能改 *it 10; // 可以元素非 const it; // 編譯錯誤迭代器本身是 const cit; // 可以迭代器可移動 *cit 10; // 編譯錯誤元素被 const 限制我第一次把這四種情況列在一起時才徹底弄清了 why。核心在于STL 迭代器用法上像指針語義上也分“指向的東西”和“自身”。把 const 用對位置能直接消除一整類編譯期問題。3.2 函數(shù)返回值加 const防止語義被誤用const 不僅可以用在參數(shù)和變量上還可以修飾函數(shù)返回值。原書舉的例子是重載運算符。像 operator* 返回 const Rational能防止用戶寫出 (a * b) c 這種荒謬的代碼。這個例子放在今天某些人眼里會覺得小題大做但它背后的問題在自定義類型里非常常見。我自己遇到過類似的場景某個類實現(xiàn)了 .value() 方法返回內(nèi)部值的引用調(diào)用方不小心把返回值賦給了一個可變引用然后修改了內(nèi)部狀態(tài)整個對象的封裝性被擊穿。如果返回值加了 const 限定編譯器會在第一時間報錯。所以我的習慣是默認情況下返回內(nèi)部狀態(tài)的 getter 要么返回值要么返回 const 引用只有當調(diào)用方確實需要修改內(nèi)部對象時才提供非 const 版本。這個習慣能擋住很多無意識的破壞。另一個容易忽略的角度是const 返回值還能讓臨時對象讀起來更安全。比如 operator 返回 const 對象時臨時對象的生命周期不會變長但它阻止了對臨時對象的修改。雖然 C11 移動語義讓某些“返回 const 對象會阻礙移動”的問題浮現(xiàn)出來但具體問題還要具體看如果返回值是自己封裝的小對象且沒有移動需求const 返回值依然是合理選擇。3.3 const 成員函數(shù)接口的“讀寫權(quán)限聲明”條款 03 后半段討論了 const 成員函數(shù)這是很多初學者最陌生、但實際項目中最常見的設計手段。給成員函數(shù)加上 const等于告訴調(diào)用方“這個函數(shù)不會修改對象的邏輯狀態(tài)”。好處有兩點一是從接口層面直接區(qū)分“讀”和“寫”使用者一看便知二是 const 對象只能調(diào)用 const 成員函數(shù)這決定了你的類能否被 const 引用安全地使用。C 對 const 成員函數(shù)的默認要求是“bitwise constness”也就是成員變量一個字節(jié)都不能變。但實際需求往往是“l(fā)ogical constness”邏輯上不該變但某些內(nèi)部緩存字段可以變。這時候需要 mutable 成員變量。class TextBlock { public: size_t length() const { if (!lengthValid) { cachedLength computeLength(); // 緩存長度 lengthValid true; } return cachedLength; } private: std::string text; mutable size_t cachedLength 0; mutable bool lengthValid false; };這個例子我拿它解釋 mutable 時幾乎所有人都能秒懂查詢長度是個只讀操作但為了提升后續(xù)查詢速度需要第一次調(diào)用時偷偷緩存結(jié)果。如果沒有 mutableconst 成員函數(shù)里就寫不了這種代碼。注意mutable 只能修飾成員變量不能修飾局部變量它是對 const 成員函數(shù)“內(nèi)部可變性”的一種精確放行。還有一個經(jīng)常被寫錯的地方const 版本和非 const 版本的成員函數(shù)可以重載但實現(xiàn)時要注意避免代碼重復。原書給的技巧是“非 const 版本調(diào)用 const 版本”利用 const_cast 去掉返回值的 const 限制。我在實際項目中一般會反過來思考先把邏輯都放進 const 版本里非 const 版本只做轉(zhuǎn)發(fā)這樣最安全因為 const 版本對所有對象都可用。但我要提醒一句const 成員函數(shù)是“承諾”不是“強制”。如果你在 const 成員函數(shù)里調(diào)用了一個非 const 成員函數(shù)編譯器會拒絕但如果你用 const_cast 強轉(zhuǎn)那等于自己撕毀了承諾一旦對象本來是真正的 const 對象修改它就是未定義行為。所以 const_cast 只能用在“你知道對象本身不是 const”的場景里比如先查緩存、再返回可變引用這種經(jīng)典寫法而不是用來繞過 const 檢查。4. 初始化不是賦值對象使用前的“四大坑”與解決套路4.1 為什么 C 的初始化規(guī)則總把人繞暈條款 04 是“確定對象被使用前已被初始化”這大概是第一章里實際踩坑最多的一條。C 的初始化問題非常擰巴有的變量不初始化就是垃圾值有的類成員的默認構(gòu)造會自動初始化有的類型比如內(nèi)置類型在你聲明時不給你任何默認值。我剛工作那年就吃過虧一個局部 bool 變量沒初始化剛好是 true程序走錯了分支排查了一下午。這里要分清兩個概念初始化和賦值。初始化是“對象一生下來就有值”賦值是“先有對象再把值放進去”。對于內(nèi)置類型這兩者在形式上看起來一樣但對于類類型初始化調(diào)用的是構(gòu)造函數(shù)賦值調(diào)用的是 operator語義完全不同。用成員初始化列表就是初始化在構(gòu)造函數(shù)體內(nèi)賦值則是“先默認構(gòu)造再賦值”后者多了一次無意義的默認構(gòu)造開銷有時還會導致不可預期的行為比如引用成員根本不能賦值。我對這條規(guī)則的執(zhí)行標準很簡單所有內(nèi)置類型成員、指針成員一律在聲明處初始化或構(gòu)造函數(shù)初始化列表中顯式初始化所有類類型成員能用初始化列表就用初始化列表。哪怕你覺得“反正默認構(gòu)造也是空的賦不賦值都一樣”也要把初始化列表寫出來因為代碼的可維護性來自“一眼能看出這個成員的值從哪里來”而不是靠推理。4.2 初始化列表與成員聲明順序的“隱形炸彈”用初始化列表時有一個特別隱蔽的規(guī)則成員的初始化順序只由它們在類中的聲明順序決定與初始化列表的書寫順序無關(guān)。也就是說即使你在初始化列表里把 y 寫在 x 前面如果類中先聲明 x實際仍然是先初始化 x再初始化 y。這個坑在“用別的成員初始化當前成員”時特別致命。例如class Point { public: Point() : y(2), x(y) {} // 看起來 y 先初始化其實還是 x 先初始化 private: int x; int y; };實際運行時x 先初始化而 x 的初始化用的是 y 的當前值——此時 y 還沒初始化是個垃圾值。于是 x 得到一個隨機數(shù)而不是預想的 2。這個 bug 編譯器通常不會警告只有開了 -Wreorder 之類的選項或者運行時輸出異常才會發(fā)現(xiàn)。我的建議是把初始化列表的書寫順序永遠和成員聲明順序保持一致并且盡量避免在成員初始化時依賴其他成員的值。依賴關(guān)系如果真的存在優(yōu)先在構(gòu)造函數(shù)體內(nèi)處理或者干脆用一個靜態(tài)函數(shù)統(tǒng)一計算。這條經(jīng)驗看著簡單但能救你很多次。4.3 跨編譯單元的 static 對象初始化次序問題經(jīng)典中的經(jīng)典條款 04 最后討論了一個更宏觀的問題不同編譯單元里定義的 static 對象的初始化次序是不確定的。這里的 static 對象包括全局對象、namespace 作用域的對象、類里的 static 對象、函數(shù)里的 static 對象以及文件作用域的 static 對象。當一個 static 對象的初始化依賴另一個編譯單元中的 static 對象時你無法保證前者初始化時后者已經(jīng)初始化完畢。假設 A.cpp 里有一個全局配置對象 ConfigManagerB.cpp 里有一個注冊表 RegistryRegistry 的構(gòu)造函數(shù)里要用 ConfigManager 去讀取配置。兩個文件誰先初始化、誰后初始化完全由鏈接順序和編譯器實現(xiàn)決定沒有任何標準保證。運行起來可能這次正常、下次崩換個編譯器直接掛在啟動階段。原書給出的解法我一直在用把“非局部 static 對象”替換成“函數(shù)內(nèi)的局部 static 對象”也就是用“構(gòu)造時初始化”的函數(shù)返回引用ConfigManager getConfigManager() { static ConfigManager instance; return instance; }這種做法被稱為 “Meyers’ Singleton” 模式雖然這里不強調(diào)單例但這個技術(shù)在單例場景最常用。C11 之后函數(shù)內(nèi) static 對象的初始化是線程安全的編譯器會生成相應的保證一次性初始化的代碼所以這個方案還順便解決了多線程環(huán)境下的初始化競爭問題。我在一個后臺服務里用這個方式管理配置、日志、連接池等組件啟動順序問題從根上消失了。這個技巧也有需要注意的地方如果兩個函數(shù)的初始化存在循環(huán)依賴A 初始化時需要 BB 初始化時需要 A這個方案同樣救不了你只能靠重構(gòu)拆解依賴。另外在 C11 之前的老編譯器上函數(shù)內(nèi) static 初始化的線程安全問題需要自己加鎖不過現(xiàn)在新項目基本默認 C17 或更高標準這個顧慮已經(jīng)很小了。5. 這些規(guī)則在今天還能怎么用我的幾條實戰(zhàn)經(jīng)驗5.1 用“四個次語言”做 Code Review 的前置分類讀完條款 01 后我形成了一套自己的 Code Review 流程先看這段代碼屬于哪個次語言再用對應次語言的標準去評價。比如一個用 STL 算法實現(xiàn)的過濾邏輯我會關(guān)注迭代器用法、算法復雜度、是否能用 lambda 簡化一個用面向?qū)ο箫L格設計的類我會關(guān)注接口設計、const 正確性、是否違反開閉原則一個模板工具函數(shù)我會關(guān)注類型推導、引用折疊、是否需要 SFINAE 或概念約束。這種分類思維能讓你在面對“這代碼寫得好不好”時給出一個更精準的答案而不是籠統(tǒng)地說“感覺不太優(yōu)雅”。C 的“好”永遠是相對的同一段代碼放在 C 風格模塊里可能不倫不類放在模板庫的擴展里可能恰到好處。5.2 const 正確性是“傳染性”的早加比晚加便宜得多const 正確性有一個特點它像一種會“傳染”的屬性。一個沒有 const 的函數(shù)調(diào)用另一個函數(shù)時如果后者是 const 成員函數(shù)前者可以安全調(diào)用但如果一個 const 對象調(diào)用了非 const 成員函數(shù)編譯器直接報錯。所以 const 加得越早后面其他代碼就越容易保持 const 安全等代碼寫完了再補 const往往是一串連鎖修改。我建議新寫的接口所有參數(shù)能加 const 引用的都加所有不修改內(nèi)部狀態(tài)的成員函數(shù)都標 const。你可以不加 const 也能編譯通過但加了 const 之后編譯器會強制你維護這個承諾長期看能擋掉很多無意的修改。這里的額外價值是當別的函數(shù)需要一個 const 對象時你的類已經(jīng)準備好了。5.3 初始化順序問題編譯器不是你的朋友而是你的敵人我最后想強調(diào)的還是初始化。每次看到有人自信地說“對象反正會默認初始化”我就想起純 C 時代的局部變量它不會默認初始化。C 在類類型上引入了默認構(gòu)造的概念但它依然不會幫你初始化內(nèi)置類型成員。很多人以為的“默認初始化”實際上是“默認不初始化”直到程序在某個隨機時間點爆出奇怪的值才意識到。我的建議是給自己定一條鐵律所有需要初始化的對象要么在聲明處初始化要么在構(gòu)造函數(shù)的初始化列表中明確寫出。不依賴“默認值”不依賴“某個函數(shù)會幫我填”不依賴“運氣”。這個習慣比任何靜態(tài)檢查工具都有效因為它從源頭消除了未定義狀態(tài)。6. 讀這一章時我踩過的幾個坑最后聊點個人體會。我第一次讀條款 02 時覺得自己早就知道 const、enum、inline 的用法沒必要逐條看。結(jié)果沒過多久就在實際項目中犯了一個教科書級的錯誤我在頭文件里寫了 #define PI 3.1415926另一個模塊剛好也定義了一個同名宏預處理階段兩個宏互相污染編譯錯誤信息里全是裸的數(shù)字。那一刻我想起條款 02 的副標題才明白“讓自己習慣C”不是讓你知道這些技巧而是讓這些技巧成為你的默認選項。另一個讓我印象深刻的坑是 static 初始化順序。當年做一個中間件插件兩個插件各自維護一個靜態(tài)注冊表一個的注冊入口依賴另一個的版本號。開發(fā)環(huán)境一切正常發(fā)布到線上偶發(fā)崩潰。后來查了幾天發(fā)現(xiàn)問題就是跨編譯單元的 static 初始化順序不確定。用局部 static 函數(shù)替換全局對象后問題徹底消失。這個經(jīng)歷讓我對“非局部 static 對象”產(chǎn)生了心理陰影——現(xiàn)在凡是看到全局配置、全局單例、全局注冊表我都會下意識去想它們的初始化依賴關(guān)系。還有一點const 成員函數(shù)里的 mutable 用得多了會讓類的線程安全性變差。比如上面那個緩存長度的例子如果兩個線程同時調(diào)用 length()mutable 的緩存字段可能被并發(fā)寫。實際工程里要么用 std::call_once 或 std::mutex 保護緩存邏輯要么干脆在文檔里注明這個類不是線程安全的。我后來給自己定了一個原則mutable 只能用于“線程邊界明確”的場景否則寧可放棄緩存也不引入數(shù)據(jù)競爭。如果你正要開始讀 Effective C 或者已經(jīng)讀到后面幾章我建議你時不時回到第一章看一眼。這不是溫故知新而是這一章講的是“思維方式”而不是“語法糖”。等你真正把“語言聯(lián)邦”“用編譯器替預處理器”“盡可能 const”“先初始化再使用”這四條刻進寫代碼的本能里后面 51 個條款讀起來會順很多。