1. 兩個(gè)“翻車現(xiàn)場(chǎng)”開場(chǎng)聲明方式選錯(cuò)代價(jià)有多大1.1 宏被當(dāng)成類型別名之后變量聲明一變就翻車寫 C/C 的人基本都在這三個(gè)名字上栽過跟頭。我最開始處理一個(gè)通信模塊時(shí)看到老代碼里有一行#define INT_PTR int*當(dāng)時(shí)覺得這不就是給int*起個(gè)別名嗎和typedef int* INT_PTR;應(yīng)該差不多吧。結(jié)果后面一行INT_PTR p1, p2;直接把整個(gè)緩沖區(qū)指針設(shè)計(jì)帶進(jìn)了坑里。展開之后其實(shí)是這樣的#define INT_PTR int* INT_PTR p1, p2;預(yù)處理器一展開變成了int* p1, p2;p1是int*而p2只是一個(gè)普通的int。如果你本意是聲明兩個(gè)指向同一塊緩沖區(qū)的指針第二個(gè)變量已經(jīng)在“類型錯(cuò)位”的狀態(tài)下參與了后續(xù)邏輯。這種錯(cuò)誤在編譯階段不會(huì)立刻暴露因?yàn)閜2還能當(dāng)整數(shù)用最麻煩的地方在于它會(huì)在運(yùn)行期制造一堆難以定位的“靈異現(xiàn)象”。換成typedef就不會(huì)有這個(gè)問題typedef int* INT_PTR; INT_PTR p1, p2;這里p1和p2都是int*。using也一樣using INT_PTR int*; INT_PTR p1, p2;這是我在實(shí)際項(xiàng)目里踩過的第一個(gè)真實(shí)教訓(xùn)。事后復(fù)盤時(shí)我意識(shí)到問題根源不在于“哪種寫法更長”而在于宏的展開機(jī)制和類型別名機(jī)制根本是兩套東西。1.2 復(fù)雜聲明里宏連“正確展開”都很難保證第二個(gè)翻車現(xiàn)場(chǎng)更典型發(fā)生在函數(shù)指針上。當(dāng)時(shí)某個(gè)線程回調(diào)模塊需要聲明多個(gè)消息處理函數(shù)指針負(fù)責(zé)人圖省事想把回調(diào)類型定義成宏。思路大概是這樣的#define MESSAGE_HANDLER void (*)(int, const char *)然后代碼里寫MESSAGE_HANDLER on_msg;大多數(shù)編譯器會(huì)直接報(bào)錯(cuò)因?yàn)檎归_之后變成了void (*)(int, const char *) on_msg;這堆東西根本不是一個(gè)合法的聲明語法。你可能覺得“加個(gè)括號(hào)不就行了”但試過就知道宏在參與復(fù)雜類型聲明時(shí)很脆稍不留神就會(huì)把聲明符拆得稀碎。后來團(tuán)隊(duì)改成typedef才把回調(diào)表穩(wěn)定下來typedef void (*MESSAGE_HANDLER)(int, const char *); MESSAGE_HANDLER on_msg;typedef之后的變量類型信息是完整的編譯器能理解、調(diào)試器也能識(shí)別。而宏只是在編譯前做字符搬運(yùn)搬運(yùn)完什么樣全看運(yùn)氣。這兩個(gè)場(chǎng)景讓我對(duì)三者的關(guān)系產(chǎn)生了強(qiáng)烈興趣為什么有的類型聲明適合用宏有的必須用 typedef后來 C11 又為什么要增加 using要真正回答這些問題得從它們的“出生時(shí)機(jī)”和“工作機(jī)制”講起。2. 先搞清楚它們?cè)凇皶r(shí)機(jī)”上的本質(zhì)差異2.1 #define 發(fā)生在編譯之前只做字符替換不產(chǎn)生類型信息#define是預(yù)處理指令工作在編譯器真正開始解析代碼之前。你可以把它理解成“編輯器的查找替換”它只對(duì)代碼中的符號(hào)做文本級(jí)展開完全不理解 C 語法也不知道什么叫類型、什么叫作用域。例如#define SIZE 100 int buf[SIZE];經(jīng)過預(yù)處理后SIZE會(huì)被替換成100。這里沒有任何類型檢查也談不上類型安全。你用#define定義“一個(gè)常量”還比較順手但如果你試圖用它“定義一個(gè)類型別名”問題就麻煩了它做的是純文本替換編譯器接觸到的已經(jīng)是替換后的代碼。它不產(chǎn)生新的類型名也不參與編譯器的符號(hào)表。它沒有作用域概念一旦定義從該位置到文件結(jié)束或者到#undef之前所有同名標(biāo)識(shí)符都會(huì)被替換。這也是為什么宏在函數(shù)式寫法里特別容易出問題。比如#define SQUARE(x) x * x然后你寫SQUARE(1 2)得到的是1 2 * 1 2結(jié)果是 5 而不是 9。這跟“類型”無關(guān)但它是宏“無腦替換”特性的一個(gè)縮影它不會(huì)因?yàn)樯舷挛亩兟斆鳌?.2 typedef 是編譯器層的“類型別名”typedef是 C 語言從早期就有的關(guān)鍵字它的作用是給一個(gè)已有的類型起一個(gè)“別名”。注意它不是創(chuàng)建新的類型而是讓兩個(gè)名字在類型系統(tǒng)里等價(jià)。typedef int MyInt; MyInt x 10;編譯器看到MyInt時(shí)會(huì)把它還原成int。在大部分場(chǎng)景里MyInt和int可以互換使用。由于這發(fā)生在編譯階段編譯器能對(duì)類型做檢查IDE 也能理解這個(gè)別名。有一個(gè)比較反直覺的細(xì)節(jié)在 C 語法里typedef被歸類為“存儲(chǔ)類說明符”和static、extern放在同一類中。但它并不分配存儲(chǔ)空間只是對(duì)聲明進(jìn)行“改寫”它把后面的聲明變成了一個(gè)“類型名”。這也是為什么有時(shí)你會(huì)看到typedef int ARRAY[10];這不是聲明一個(gè)叫ARRAY的變量而是把ARRAY定義成“長度為 10 的 int 數(shù)組類型”。之后寫ARRAY arr;等價(jià)于int arr[10];。理解了這一點(diǎn)你就知道#define和typedef根本不是一回事前者不進(jìn)入編譯器的類型系統(tǒng)后者天生就是類型系統(tǒng)的一部分。2.3 using 是 C11 的別名聲明并補(bǔ)上了模板別名using作為“類型別名聲明”的寫法是從 C11 開始正式加入標(biāo)準(zhǔn)的。它的形式更直觀using NewName OldType;比如using Byte unsigned char; using Handler void (*)(int); using StringPtr std::string*;這種寫法把“類型名”放到左邊把“被替代的類型”放到右邊比typedef更符合大多數(shù)人的閱讀習(xí)慣。更重要的是using支持模板別名而typedef做不到?？匆粋€(gè)實(shí)際場(chǎng)景。假設(shè)你想給std::vectorT起一個(gè)別名typedef沒法“半定義”一個(gè)模板// 這樣寫會(huì)編譯失敗因?yàn)?typedef 后面不能跟著 template // templatetypename T // typedef std::vectorT Vec; // 不行但using可以template typename T using Vec std::vectorT;之后你就能寫Vecint、Vecstd::string這種能力在泛型編程里特別有用。比如寫一個(gè)“默認(rèn)分配器的 vector 別名”或者給某個(gè)復(fù)雜的模板類型指定固定參數(shù)using都比typedef干凈得多。所以時(shí)間線上看#define是最古老的手段typedef是 C 語言規(guī)范的“正規(guī)軍”using是 C11 給 C 開發(fā)者補(bǔ)充的現(xiàn)代寫法。3. 類型語義上的差距const、指針、數(shù)組、函數(shù)指針3.1 const 修飾符同樣一行代碼含義完全相反這是我在面試和實(shí)際審查中都很喜歡問的點(diǎn)。別看都是一行“加 const”放在宏后面和放在別名后面結(jié)果完全相反。先看typedeftypedef int* PTR; const PTR p;這里p是int* const也就是“一個(gè)本身不能改指向的指針”但指針指向的int可以被修改。因?yàn)閏onst修飾的是PTR這個(gè)別名整體相當(dāng)于對(duì)一個(gè)指針類型的變量加頂層 const。再看宏#define PTR int* const PTR p;展開后成為const int* p;這變成了“指向 const int 的指針”也就是說指針本身可以改它可以指向別的int但你不能通過p修改int的值。同一個(gè)const意義上差了十萬八千里。如果你不小心把兩種混在一個(gè)項(xiàng)目里很容易出現(xiàn)“這個(gè) p 為什么不能賦值了”“為什么換個(gè)地址就報(bào)錯(cuò)”這類問題。很多老工程師碰上這種狀況第一反應(yīng)是查指針的用法很少會(huì)想到問題出在聲明方式上。用using也是一樣的using PTR int*; const PTR p;這個(gè)和typedef的情況相同p是int* const。所以只要涉及const和指針組合我強(qiáng)烈建議優(yōu)先用 typedef/using別用宏去扛。3.2 多變量聲明typedef 和 using 更符合直覺宏的“多個(gè)變量聲明”問題其實(shí)我在開頭已經(jīng)提過。再補(bǔ)一個(gè)更細(xì)節(jié)的例子#define CP const char* CP a, b;展開后const char* a, b;a是const char*b只是char。如果你寫成typedef const char* CP;那a、b都會(huì)是const char*。用using同理。這種問題在代碼評(píng)審里特別容易被漏掉因?yàn)榭雌饋砭褪钦R齊的一行。只有當(dāng)你需要兩個(gè)指針同時(shí)指向不同字符串時(shí)運(yùn)行期才會(huì)突然發(fā)現(xiàn)第二個(gè)變量根本不能當(dāng)指針用。所以我的經(jīng)驗(yàn)是如果代碼里出現(xiàn)“類型別名 一行多變量聲明”不要用宏?？赡苣阌X得“宏寫起來短”但這個(gè)短會(huì)讓你搭上好幾個(gè)小時(shí)的排查時(shí)間。3.3 數(shù)組和函數(shù)指針typedef/using 的舒適區(qū)數(shù)組類型用宏定義也很別扭。比如你想定義一個(gè)“4 個(gè) int 的數(shù)組類型”typedef int ARRAY4[4]; ARRAY4 arr;arr就是int[4]。如果試圖寫成#define ARRAY4 int[4] ARRAY4 arr;展開后變成int[4] arr;這顯然不是合法聲明。C 語法里數(shù)組類型的聲明方式本身就和普通變量不一樣宏根本處理不了這種“類型抽象”。函數(shù)指針同理。聲明一個(gè)函數(shù)指針變量通常是using Callback int (*)(int, int); Callback fn nullptr;using把這個(gè)看起來復(fù)雜的類型封裝成一個(gè)名字調(diào)用和傳參都會(huì)清爽很多。C 語言里一般用typedeftypedef int (*Callback)(int, int); Callback fn;而用宏去定義函數(shù)指針類型前面已經(jīng)展示過基本是災(zāi)難。因?yàn)楹瘮?shù)指針類型具有“可調(diào)用的類型”屬性宏的文本替換機(jī)制理解不了這種抽象。4. 作用域、重復(fù)聲明與可讀性宏的“全局污染”問題4.1 宏沒有作用域這是一個(gè)很隱蔽但危害極大的區(qū)別。typedef和using寫在一個(gè)塊里就只在該塊內(nèi)生效寫在一個(gè)命名空間里C就只在該命名空間內(nèi)可見。而宏沒有這種概念它從定義位置開始一路橫沖直撞到文件結(jié)束除非碰到#undef。舉一個(gè)例子#define MAX_LEN 100 void foo() { int MAX_LEN 5; // 預(yù)處理器會(huì)把它展開成 int 100 5; }這段代碼根本編譯不過因?yàn)镸AX_LEN會(huì)被展開成100。你可能覺得“正常沒有人會(huì)取這樣的變量名”但大型項(xiàng)目里宏往往來自第三方頭文件、平臺(tái)適配層、配置開關(guān)你根本不知道哪一行被某個(gè)宏盯上了。這就是“全局污染”一個(gè)宏不僅僅影響你想要影響的常量或類型它會(huì)影響所有后續(xù)代碼里的同名標(biāo)識(shí)符。項(xiàng)目中很多離奇的編譯錯(cuò)誤最后查出來都是某個(gè)頭文件里宏名和變量名撞車。相比之下typedef和using是真正進(jìn)入編譯器的“名字”它們遵守作用域規(guī)則可以在局部塊、函數(shù)、類、命名空間內(nèi)定義不會(huì)像宏那樣無差別擴(kuò)散。4.2 typedef 和 using 的重復(fù)定義規(guī)則宏可以用#undef在中間取消然后再重新定義。這是預(yù)處理指令的優(yōu)勢(shì)但從類型安全角度來說也是它的風(fēng)險(xiǎn)你無法保證同一個(gè)宏名在不同文件中到底代表什么。#define FLAG 1 ... #undef FLAG #define FLAG 2這種寫法很靈活但代碼可追溯性差。而typedef和using在同作用域內(nèi)重復(fù)定義有嚴(yán)格限制。按標(biāo)準(zhǔn)同作用域內(nèi)把同一個(gè)名字重復(fù)定義為同一個(gè)類型是允許的typedef int MyInt; typedef int MyInt; // C 和 C 多數(shù)實(shí)現(xiàn)允許但如果你試圖把MyInt重新定義成別的類型typedef int MyInt; typedef long MyInt; // 錯(cuò)誤與已有類型沖突編譯器會(huì)直接報(bào)錯(cuò)。using也基本遵循相同邏輯。這種“鎖死”反而是一種保護(hù)它迫使你在不同作用域或不同命名空間里處理命名沖突而不是悶著頭覆蓋。4.3 可讀性和 IDE 智能感知的差距宏的代碼在 IDE 里很“鈍”。因?yàn)槟愣x的類型別名實(shí)際上是文本片段IDE 很難做準(zhǔn)確的跳轉(zhuǎn)、重命名和類型提示。你跳到一個(gè)宏定義上看到的往往就是一堆預(yù)處理展開邏輯編譯器報(bào)錯(cuò)時(shí)報(bào)的也可能是展開后的奇怪片段。typedef和using則有明確的“類型名”IDE 能把你跳轉(zhuǎn)到別名定義能顯示完整類型也能在重構(gòu)時(shí)幫你統(tǒng)一改名。這一點(diǎn)在大型項(xiàng)目里非常重要代碼不是寫給自己看的是給后面三撥維護(hù)的人看的。類型別名如果用宏去偽裝維護(hù)成本會(huì)成倍上升。5. 模板別名與選型規(guī)則現(xiàn)代 C 該怎么選5.1 using 不只是語法糖它補(bǔ)上了 typedef 的短板很多初學(xué)者覺得using只是“換了個(gè)方向?qū)?typedef”其實(shí)不止。typedef最大的短板是不支持模板別名而模板別名在現(xiàn)代 C 的泛型設(shè)計(jì)中特別常見。舉個(gè)例子你想定義一個(gè)“總是使用自定義分配器的字符串類型”template typename T using MyVec std::vectorT, MyAllocatorT;這段代碼如果用typedef寫會(huì)非常別扭甚至需要額外包一層結(jié)構(gòu)體。而using直接用等號(hào)把“一個(gè)模板的實(shí)例化結(jié)果”綁定到新名字上自然得多MyVecint ids; MyVecstd::string names;當(dāng)然如果你寫的還是 C98/03 的老項(xiàng)目using這種寫法用不了只能繼續(xù)用typedef或者“模板 struct 提取 type”的老方案。但從 C11 開始新代碼優(yōu)先使用using幾乎成了共識(shí)。5.2 實(shí)際項(xiàng)目中的選型建議我給自己定的規(guī)則很簡單可以列成一張表場(chǎng)景優(yōu)先選擇原因C 代碼、跨 C/C 的公共頭文件typedefC 語言不支持usingC11 及以上的新代碼using可讀性好支持模板別名模板類型別名只能用usingtypedef沒有這個(gè)能力include guard、條件編譯、編譯開關(guān)#define這些本來就是預(yù)處理器的職責(zé)普通常量constexpr/enum不要用#define作用域和類型更安全把一部分函數(shù)簽名封裝成回調(diào)類型typedef或using編譯器可檢查IDE 可識(shí)別這里面要特別強(qiáng)調(diào)一點(diǎn)宏并沒有被“淘汰”它在 include guard、平臺(tái)適配、日志開關(guān)、斷言開關(guān)等場(chǎng)景下依然不可替代。真正的問題是有人拿宏去干“類型別名”的活那才是災(zāi)難。5.3 從 typedef 遷移到 using 的注意點(diǎn)如果你想把老代碼里的typedef改成using大多數(shù)普通類型別名是直接等價(jià)的typedef int* IntPtr; using IntPtr int*;但要注意涉及“匿名結(jié)構(gòu)體”的 C 代碼比如typedef struct { int x; int y; } Point;這種寫法在 C 里很常見轉(zhuǎn)換到 C 時(shí)可以用using Point struct { ... };嗎不同編譯器支持情況不一而且這種代碼往往還承擔(dān)著 C/C 兼容的職責(zé)。所以我建議如果是 C 和 C 混編的公共頭文件老老實(shí)實(shí)保留typedef別為了“現(xiàn)代感”強(qiáng)行改。新寫的 C 源碼內(nèi)部再大膽使用using。6. 避坑清單哪些寫法是我實(shí)戰(zhàn)中踩過的坑6.1 宏最危險(xiǎn)的地方不是“慢”而是“像類型卻不是類型”關(guān)于宏我之前有個(gè)很深的教訓(xùn)它展開時(shí)不會(huì)檢查語義所以最容易出現(xiàn)的是“看起來沒毛病跑起來不對(duì)”。舉幾個(gè)常見雷區(qū)#define PTR int*配合PTR a, b;只有一個(gè)是指針。#define CP const char*配合const CP p;修飾效果變成“指向 const 的指針”。#define CALLBACK void(*)(int)直接聲明變量時(shí)語法報(bào)錯(cuò)。宏參數(shù)不加括號(hào)導(dǎo)致運(yùn)算優(yōu)先級(jí)被破壞。宏名和局部變量撞車導(dǎo)致局部變量被無腦替換。我現(xiàn)在的底線是只要我發(fā)現(xiàn)代碼里有人用宏定義“函數(shù)簽名類型”或“指針類型”在評(píng)審階段就會(huì)建議改成typedef或using。這不是潔癖是真的會(huì)省掉后續(xù)大量的排錯(cuò)時(shí)間。6.2 typedef/using 也不是萬能別名層級(jí)太多會(huì)反噬typedef和using確實(shí)更安全但也存在一個(gè)常見問題別名套別名最終把真實(shí)的類型信息藏得嚴(yán)嚴(yán)實(shí)實(shí)。我見過這樣的代碼using SPtr std::shared_ptrint; using SPtrList std::vectorSPtr; using SPtrListPtr SPtrList*;等等最后讀代碼的人還要一層層拆開才知道SPtrListPtr到底是什么。類型別名是為了讓代碼更清晰不是為了制造謎題。如果你的別名已經(jīng)需要三四個(gè)層級(jí)才能還原出真實(shí)類型那它帶來的溝通成本可能已經(jīng)大于收益。我的習(xí)慣是別名要做到“看到名字就能猜出大致類型”。比如Callback、Byte、StringList這類語義明確但X2、PTR2、HANDLE_A這種含糊的別名趁早改掉。另外調(diào)用函數(shù)時(shí)如果實(shí)參類型和別名接不上編譯器報(bào)錯(cuò)信息里經(jīng)常會(huì)列出完整展開路徑那也是排查的重要信息來源。6.3 讀代碼時(shí)的快速判斷法這是我在最后想分享的一個(gè)實(shí)操技巧當(dāng)一個(gè)老項(xiàng)目里出現(xiàn)“看起來像類型名”的標(biāo)識(shí)符時(shí)怎么快速判斷它是宏還是真正的別名先去搜索它的定義位置。如果定義來自預(yù)處理指令#define那就按宏的邏輯去推它的作用域是全局的它不會(huì)參與類型檢查任何和它相關(guān)的奇怪行為都要先懷疑展開后的文本。如果定義是typedef或using那就按類型系統(tǒng)的邏輯去讀它有作用域可以重定義能參與 const/指針組合IDE 一般能準(zhǔn)確跳轉(zhuǎn)。再看命名風(fēng)格。宏通常用全大寫加下劃線比如MAX_BUF_LEN、_LOCK_ENABLE因?yàn)檫@是社區(qū)通用的“降低沖突概率”方式。typedef/using 的別名在 C 項(xiàng)目里更常見的是駝峰或語義化命名。當(dāng)然老 C 項(xiàng)目里也可能出現(xiàn)typedef int INT32;這種風(fēng)格所以不能只看大小寫還是要找定義。最后落實(shí)到寫法偏好我自己的代碼里能不用宏做類型相關(guān)的事就不用。include guard、條件編譯交給#define常量交給constexpr類型別名交給typedef或using。這不是說宏沒有價(jià)值而是要把它放在它擅長的場(chǎng)景里。實(shí)際經(jīng)歷過幾次“宏冒充類型”帶來的排查后你會(huì)越來越認(rèn)同一個(gè)樸素的結(jié)論類型相關(guān)的事情就應(yīng)該交給類型系統(tǒng)自己的工具去處理。