雖然 C 語言并不是我所學(xué)的第一門語言，也不是我的最后一門語言，但是我仍然非常喜歡 C，當(dāng)需要寫程序時(shí)，我的第一選擇還是 C。同時(shí)，我也會(huì)關(guān)注現(xiàn)代編程語言及其發(fā)展趨勢(shì)，而且我還使用 Rust 編寫了自己的業(yè)務(wù)愛好項(xiàng)目。那么，為什么我沒有拋棄 C 而選擇其他語言呢？我對(duì)于 C++的看法又是如何的呢？

1 為什么說C不是最好的語言？

首先，這個(gè)世上沒有最好的編程語言。每種語言都有獨(dú)特的優(yōu)勢(shì)以及適用情況，所以盡管你可以在 Excel 中編寫光線追蹤程序，但最好還是使用其他語言。因此，我們都需要了解編程語言的限制，不要抱怨 Web 服務(wù)器不是用 Fortran 編寫的，也不要抱怨基本沒有任何應(yīng)用使用 Perl 或 C++作為內(nèi)部腳本語言。我認(rèn)為 C 語言不太理想的方面包括以下幾點(diǎn)。 除了 C 比較老，發(fā)展不快之外，當(dāng)然還與個(gè)人的喜好有關(guān)。 其次，有些時(shí)候，C 的語言不夠明確。比如，*可以是二進(jìn)制乘法運(yùn)算符、一元解引用運(yùn)算符，也可用于聲明指針。 再者，有些情況不夠安全，例如越界訪問數(shù)組這種極其常見的錯(cuò)誤都沒有運(yùn)行時(shí)檢查，這一點(diǎn)連 Borland Pascal 都比不了，更不用說更現(xiàn)代的編程語言了（盡管你會(huì)為了提高性能關(guān)閉這個(gè)編譯選項(xiàng)）。此外，指針讓我們很難保持一切井然有序。再加上一些其他情況，比如調(diào)用函數(shù)不需要事先聲明原型，這樣很容易將錯(cuò)誤類型的參數(shù)傳遞給函數(shù)。 最后，C 的標(biāo)準(zhǔn)庫非常有限。有些編程語言甚至擁有開箱即用的 Web 服務(wù)器（或者至少有構(gòu)建 Web 服務(wù)器所需的所有模塊），但 C 標(biāo)準(zhǔn)庫甚至連 Web 服務(wù)器的容器也沒有。

2 為什么我還是喜歡C？

盡管如此，我還是十分喜歡 C，因?yàn)樗且环N簡單的語言。從某種意義上說很簡單，很容易表達(dá)自己的想法以及期望。 舉個(gè)例子，假設(shè)兩個(gè)數(shù)組有兩個(gè)偏移量，其中一個(gè)可以為負(fù)數(shù)，如果使用C語言編寫，則可以寫成： arr[off1+off2] 如果是Rust，則需要寫成： arr[((off1asisize)+off2)asusize] 通常，C 的循環(huán)也比 Rust 的迭代器組合更為簡潔（當(dāng)然 Rust 也允許使用前一種方式，但 linter 并不滿意，它會(huì)建議你使用迭代器來代替）。類似地，memset()和 memmove()也是功能十分強(qiáng)大的工具。 在大多數(shù)情況下，你都可以預(yù)見到編譯的結(jié)果，即對(duì)象在內(nèi)存中的表示方式，以及如何通過不同的方式理解編譯后的結(jié)果（新版 C 標(biāo)準(zhǔn)中這一點(diǎn)變得更困難，這都要怪 C++，我稍后再詳細(xì)介紹）。另外，你也很清楚函數(shù)調(diào)用的結(jié)果等等。由于這個(gè)原因，C 被稱為可移植的匯編語言，所以我非常喜歡 C。 我們拿汽車做個(gè)類比，C 語言就像一輛跑車，擁有手動(dòng)變速箱，可以提供最佳性能，但是如果你不熟悉離合器和掛擋操作，那么變速箱很容易被損壞，甚至可能損壞發(fā)動(dòng)機(jī)，當(dāng)然，油門踩得過大也有可能沖出馬路。然而，與自動(dòng)變速箱相比，這種車輛的發(fā)動(dòng)機(jī)能量更大，而且你可以預(yù)測(cè)性能，還可以炫車技，這些在其他車輛上都是不可能的。

3 這與C++有什么關(guān)系？

下面，我們來說一說 C++，其實(shí)我不討厭 C++。我不能否認(rèn)，與 C 相比， C++ 擁有兩個(gè)優(yōu)點(diǎn)：

更好的程序結(jié)構(gòu)：C++ 擁有命名空間和類，而且在某些方面Simula還是很出色的。

擁有 RAII 概念：一個(gè)簡單的例子就是 C++ 擁有構(gòu)造函數(shù)，可在創(chuàng)建對(duì)象時(shí)初始化對(duì)象；還擁有析構(gòu)函數(shù)，在銷毀對(duì)象時(shí)，做一些清理的工作。這個(gè)概念進(jìn)一步發(fā)展，就接近 Rust 的生命周期了。

另一方面，C++ 有兩個(gè)特征，我非常不喜歡。 首先是這門語言的整體性質(zhì)。其他編程語言擁有的流行功能最終都會(huì)進(jìn)入 C++。因此，每過幾年，C++標(biāo)準(zhǔn)就會(huì)添加一些新功能。最終，這門語言就變得有點(diǎn)怪異，沒人能夠完全掌握，而且許多功能都是抄襲的其他語言?；旧厦總€(gè)人在編寫代碼的時(shí)候，都會(huì)選擇一個(gè) C++的子集，然后忽略其他功能的存在。另外，我們究竟應(yīng)該使用哪個(gè) C++版本的功能，并沒有一套標(biāo)準(zhǔn)的方法。Rust 在包的范圍內(nèi)提供了版本管理。據(jù)我所知，C++也曾嘗試過引入“代際”的概念來實(shí)現(xiàn)同樣的功能，但沒有成功。我經(jīng)常聽到有人獨(dú)自編寫 C 編譯器，卻從來沒聽說過有人編寫 C++編譯器。 其次，實(shí)際上 C++不僅是多種語言，而且還是一種元語言（即模板）。我了解 C++的創(chuàng)建初衷，也同意它對(duì)于與類型無關(guān)的代碼的處理，比 C 預(yù)處理器更好。但實(shí)際上，它產(chǎn)生的代碼十分可怕，原本是“頭文件僅包含聲明，實(shí)現(xiàn)放在編譯好的代碼中”，變成了“頭文件包含所有項(xiàng)目會(huì)用到的代碼”。我不喜歡過于冗長的編譯時(shí)間，但這種方式只能讓情況更糟。 最后，我覺得 C++的出現(xiàn)反而給 C 帶來了約束以及不良影響。我不是在討論 C/C++，也不是指 C 與 C++的共通之處，我討論的是耦合對(duì)標(biāo)準(zhǔn)和編譯器都有不良影響。一方面，C++建立在 C 之上，從而得到了極大的發(fā)展；另一方面，如果 C++中沒有 C 遺留下來的大多數(shù)功能的話，情況可能會(huì)更好（當(dāng)然，C++曾設(shè)法通過淘汰的方式逐步放棄某些 C 功能，但對(duì)于舊功能的支持仍然存在）。但是，C++ 24 能夠在 C++ 21 的基礎(chǔ)之上，發(fā)展成為一門獨(dú)立的編程語言嗎？大多數(shù)過時(shí)的功能都可以拋棄嗎？我對(duì)此表示懷疑。

4 C++編譯器對(duì)C的影響

實(shí)際上，C 語言被當(dāng)成了沒有某些功能的 C++。比如微軟的 C 編譯器直到2015 版才開始支持 C99 功能（即便如此，它還是以 bug 修復(fù) bug 的方式來支持兼容性，因?yàn)榭蛻艨赡軙?huì)震驚地發(fā)現(xiàn)可變參數(shù)宏居然可以運(yùn)行）。但是，無論是標(biāo)準(zhǔn)的編譯器還是其他編譯器中都可以看到相同的方法，這些都是相關(guān)的問題。 主要問題在于，C 和 C++標(biāo)準(zhǔn)都是根據(jù)編譯器開發(fā)人員的反饋而編寫的，而且大多數(shù)都是 C++開發(fā)人員（有些人對(duì)現(xiàn)實(shí)世界編程一無所知，而且他們還認(rèn)為現(xiàn)實(shí)世界的做法與自己的觀點(diǎn)完全吻合，真是令人窒息的操作）。雖然我也沒有遵循標(biāo)準(zhǔn)的開發(fā)程序，但是我很確定 C99 及其后版本中令人討厭的諸多功能皆來自那些編譯器開發(fā)人員。他們只從 C++的角度出發(fā)考慮，而且還將這些功能強(qiáng)加給了 C，還美其名曰簡化編譯器。 當(dāng)然我指的是“未定義的行為”以及編譯器的處理方式。這已成為一大毒瘤（只要你的代碼依賴于二進(jìn)制補(bǔ)碼算術(shù)，就會(huì)被認(rèn)定具有未定義的行為，編譯器會(huì)拋棄整塊代碼）。 在我看來，以下四種行為盡管不值得提倡，但前兩個(gè)也并非不可接受：

依賴于體系結(jié)構(gòu)的行為（即依賴于 CPU 體系結(jié)構(gòu)的行為）。包括絕大部分算術(shù)運(yùn)算。例如，如果我知道目標(biāo)及其使用了兩個(gè)協(xié)處理器，為什么編譯器會(huì)選擇另一種方式，僅僅是為了獲得理論上的優(yōu)化？同樣的問題也適用于移位運(yùn)算。如果我知道 x86 會(huì)忽略移位偏移量的高比特，在 ARM 上負(fù)的左移相當(dāng)于右移，那么為什么不能專門針對(duì)該體系結(jié)構(gòu)編寫程序呢？畢竟，連整數(shù)的大小在不同平臺(tái)上都不一樣。這種不可移植性只需警告就好，讓用戶自行處理。

指針魔法和類型雙關(guān)。這似乎又是編譯器優(yōu)化帶來的限制。我同意，在重疊的內(nèi)存區(qū)域上使用 memcpy()，不同的實(shí)現(xiàn)可能會(huì)給出不同的行為（現(xiàn)代的 x86 實(shí)現(xiàn)會(huì)從區(qū)域尾部開始復(fù)制），而且還依賴于地址的相對(duì)位置，但其他的規(guī)則就沒什么道理了。例如，無法使用兩個(gè)不同類型的指針同時(shí)操作同一塊內(nèi)存區(qū)域。我無法想象為什么這種行為被禁止，其原因只可能是編譯器優(yōu)化。這樣就不可能利用聯(lián)合體將整數(shù)轉(zhuǎn)換成浮點(diǎn)數(shù)。Linus 也曾吐槽過這一點(diǎn)，我就不用重復(fù)了。但在我看來，這樣做的目的或者是更好的編譯器優(yōu)化，或者是出于 C++的要求（由于類型跟蹤的要求）。

實(shí)現(xiàn)中定義的行為（即超出 C 標(biāo)準(zhǔn)規(guī)定的行為）。我常用的例子就是函數(shù)調(diào)用：根據(jù)調(diào)用的習(xí)慣約定和編譯器的實(shí)現(xiàn)，函數(shù)的參數(shù)的求值順序可能完全是隨機(jī)的，因此 foo(*ptr++, *ptr++, *ptr++)的結(jié)果是未定義的，因此即使你知道目標(biāo)體系結(jié)構(gòu)，也不應(yīng)該依賴于這種行為。

完全未定義的行為。最常見的例子就是在一條語句中改變變量狀態(tài)，例如著名的 I++ + i++，或者更甚的 *ptr++ = *ptr++ +*ptr++。

由于 C++比 C 更高級(jí)（盡管它由許多來自 C 的特性，但都不建議使用，應(yīng)該使用 reinterpret_cast<>代替類型轉(zhuǎn)換，用引用代替指針，等等），所以不要期待 C++程序員能夠像 C 程序員那樣理解底層代碼。當(dāng)然，由于 C++程序員占絕大多數(shù)，C/C++的耦合也極其常見，所以 C 編譯器通常會(huì)進(jìn)行擴(kuò)展以支持C++，并使用 C++重寫，以適應(yīng)其復(fù)雜度。所以很不幸，你不得不使用 C++編譯器來編譯 C 編譯器（還好我們還有 LCC、PCC 和 TCC 等純 C 編譯器）。

5 總結(jié)

總的來說，我喜歡C所處的中層位置，它既可以完成一些底層的實(shí)現(xiàn)，例如輕松地操作內(nèi)存，同時(shí)又可以享受高級(jí)語言的好處。另一方面，我對(duì)C++強(qiáng)烈的不滿來自其在設(shè)計(jì)上的選擇，而且這些設(shè)計(jì)影響了C標(biāo)準(zhǔn)和編譯器。 至少我不可能用 C90 特別版取代 C90，并假裝原來的版本不存在。