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

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

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

2 為什么我還是喜歡C？

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

3 這與C++有什么關系？

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

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

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

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

4 C++編譯器對C的影響

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

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

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

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

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

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

5 總結

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