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

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

首先，這個世上沒有最好的編程語言。每種語言都有獨特的優勢以及適用情況，所以盡管你可以在 Excel 中編寫光線追蹤程序，但最好還是使用其他語言。因此，我們都需要了解編程語言的限制，不要抱怨 Web 服務器不是用 Fortran 編寫的，也不要抱怨基本沒有任何應用使用 Perl 或 C++作為內部腳本語言。我認為 C 語言不太理想的方面包括以下幾點(除了 C 比較老，發展不快之外，當然還與個人的喜好有關)。

其次，有些時候，C 的語言不夠明確。比如，*可以是二進制乘法運算符、一元解引用運算符，也可用于聲明指針。

再者，有些情況不夠安全，例如越界訪問數組這種極其常見的錯誤都沒有運行時檢查，這一點連 Borland Pascal 都比不了，更不用說更現代的編程語言了(盡管你會為了提高性能關閉這個編譯選項)。此外，指針讓我們很難保持一切井然有序。再加上一些其他情況，比如調用函數不需要事先聲明原型，這樣很容易將錯誤類型的參數傳遞給函數。

最后，C 的標準庫非常有限。有些編程語言甚至擁有開箱即用的 Web 服務器(或者至少有構建 Web 服務器所需的所有模塊)，但 C 標準庫甚至連 Web 服務器的容器也沒有。

為什么我還是喜歡C?

盡管如此，我還是十分喜歡 C，因為它是一種簡單的語言。從某種意義上說很簡單，很容易表達自己的想法以及期望。

舉個例子，假設兩個數組有兩個偏移量，其中一個可以為負數，如果使用C語言編寫，則可以寫成：

arr[off1 + off2]

如果是Rust，則需要寫成：

arr[((off1 as isize) + off2) as usize]

通常，C 的循環也比 Rust 的迭代器組合更為簡潔(當然 Rust 也允許使用前一種方式，但 linter 并不滿意，它會建議你使用迭代器來代替)。類似地，memset()和 memmove()也是功能十分強大的工具。

在大多數情況下，你都可以預見到編譯的結果，即對象在內存中的表示方式，以及如何通過不同的方式理解編譯后的結果(新版 C 標準中這一點變得更困難，這都要怪 C++，我稍后再詳細介紹)。另外，你也很清楚函數調用的結果等等。由于這個原因，C 被稱為可移植的匯編語言，所以我非常喜歡 C。

我們拿汽車做個類比，C 語言就像一輛跑車，擁有手動變速箱，可以提供最佳性能，但是如果你不熟悉離合器和掛擋操作，那么變速箱很容易被損壞，甚至可能損壞發動機，當然，油門踩得過大也有可能沖出馬路。然而，與自動變速箱相比，這種車輛的發動機能量更大，而且你可以預測性能，還可以炫車技，這些在其他車輛上都是不可能的。

這與C++有什么關系?

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

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

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

另一方面，C++ 有兩個特征，我非常不喜歡。

首先是這門語言的整體性質。其他編程語言擁有的流行功能最終都會進入 C++。因此，每過幾年，C++標準就會添加一些新功能。最終，這門語言就變得有點怪異，沒人能夠完全掌握，而且許多功能都是抄襲的其他語言。基本上每個人在編寫代碼的時候，都會選擇一個 C++的子集，然后忽略其他功能的存在。另外，我們究竟應該使用哪個 C++版本的功能，并沒有一套標準的方法。Rust 在包的范圍內提供了版本管理。據我所知，C++也曾嘗試過引入“代際”的概念來實現同樣的功能，但沒有成功。我經常聽到有人獨自編寫 C 編譯器，卻從來沒聽說過有人編寫 C++編譯器。

其次，實際上 C++不僅是多種語言，而且還是一種元語言(即模板)。我了解 C++的創建初衷，也同意它對于與類型無關的代碼的處理，比 C 預處理器更好。但實際上，它產生的代碼十分可怕，原本是“頭文件僅包含聲明，實現放在編譯好的代碼中”，變成了“頭文件包含所有項目會用到的代碼”。我不喜歡過于冗長的編譯時間，但這種方式只能讓情況更糟。

最后，我覺得 C++的出現反而給 C 帶來了約束以及不良影響。我不是在討論 C/C++，也不是指 C 與 C++的共通之處，我討論的是耦合對標準和編譯器都有不良影響。一方面，C++建立在 C 之上，從而得到了極大的發展;另一方面，如果 C++中沒有 C 遺留下來的大多數功能的話，情況可能會更好(當然，C++曾設法通過淘汰的方式逐步放棄某些 C 功能，但對于舊功能的支持仍然存在)。但是，C++ 24 能夠在 C++ 21 的基礎之上，發展成為一門獨立的編程語言嗎?大多數過時的功能都可以拋棄嗎?我對此表示懷疑。

C++編譯器對C的影響

實際上，C 語言被當成了沒有某些功能的 C++。比如微軟的 C 編譯器直到2015 版才開始支持 C99 功能(即便如此，它還是以 bug 修復 bug 的方式來支持兼容性，因為客戶可能會震驚地發現可變參數宏居然可以運行)。但是，無論是標準的編譯器還是其他編譯器中都可以看到相同的方法，這些都是相關的問題。

主要問題在于，C 和 C++標準都是根據編譯器開發人員的反饋而編寫的，而且大多數都是 C++開發人員(有些人對現實世界編程一無所知，而且他們還認為現實世界的做法與自己的觀點完全吻合，真是令人窒息的操作)。雖然我也沒有遵循標準的開發程序，但是我很確定 C99 及其后版本中令人討厭的諸多功能皆來自那些編譯器開發人員。他們只從 C++的角度出發考慮，而且還將這些功能強加給了 C，還美其名曰簡化編譯器。

當然我指的是“未定義的行為”以及編譯器的處理方式。這已成為一大毒瘤(只要你的代碼依賴于二進制補碼算術，就會被認定具有未定義的行為，編譯器會拋棄整塊代碼)。

在我看來，以下四種行為盡管不值得提倡，但前兩個也并非不可接受：

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

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

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

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

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

總 結

總的來說，我喜歡C所處的中層位置，它既可以完成一些底層的實現，例如輕松地操作內存，同時又可以享受高級語言的好處。另一方面，我對C++強烈的不滿來自其在設計上的選擇，而且這些設計影響了C標準和編譯器。

至少我不可能用 C90 特別版取代 C90，并假裝原來的版本不存在。