C與C＋40 年的愛恨情仇
作者 |?cor3ntin
譯者 | 彎月，責編 |?鄭麗媛
頭圖 | CSDN 下載自視覺中國
出品 | CSDN（ID：CSDNnews）
以下為譯文：
70年代初，貝爾實驗室創建了C語言，它是開發UNIX的副產品。很快C就成為了最受歡迎的編程語言之一。但是對於Bjarne Stroustrup來說，C的表達能力還不夠。於是，他在1983年的博士論文中擴展了C語言。
於是，支持類的C語言誕生了。
當時，Bjarne Stroustrup明白編程語言有許多組成部分，除了語言本身，還有編譯器、鏈接器和各種庫。提供熟悉的工具有助於語言被廣泛接受。在這種歷史背景下，在C語言的基礎上開發C 也是有道理的。
40年後，C和C 都在行業中得到了廣泛使用。但是，互聯網上的C開發人員認為C 是有史以來最糟糕的人類發明，而許多C 開發人員則希望有朝一日C語言灰飛煙滅。
究竟發生了什麼事？
從表面上看，C和C 都可以滿足相同的用例：高性能、確定性、原生但可移植的代碼，可用於最廣泛的硬體和應用程序。
但是，更讓C自豪的是它是一門低級語言，更接近彙編。
而C ，從誕生第一天開始就充斥了各種奇怪的東西。例如析構函數這個黑魔法。自作主張的編譯器。儘管很早C 就有了類型推斷功能，但是80年代中期的開發人員還無法接受這個概念，因此Bjarne Stroustrup不得不刪除了auto，直到C 11又重新添加回來。
從那以後，C 就不斷加入各種工具來實現抽象。很難說C 是一種低級語言還是高級語言。從設計目的上來說，C 兩者都是。但是在不犧牲性能的情況下，建立高級抽象是很困難的。於是C 引入了各種工具來實現constexpr、move語義、模板和不斷增長的標準庫。
從根本上講，我認為C信任開發人員，而C 信任編譯器。這是一個巨大的差異，單憑「兩者的原生類型相同」、「while循環的語法相同」等簡單一致是無法掩蓋的。
C 開發人員將有這些問題歸咎於C，而C開發人員則認為C 過於瘋狂。我覺得站在C的角度看C ，這種說法也很正確。作為C的超集，C 確實很瘋狂。一個經驗豐富的C開發人員面對C 可能沒有熟悉的感覺。C 不是C，這就足以引發互聯網上的激烈爭論。
然而，雖然我不喜歡C，但也沒有權利取笑C。儘管我有一定的C 經驗，但用C編寫過的代碼少之又少，而且肯定是很糟糕的代碼。好的編程語言包括良好的實踐、模式、慣用寫法，這些都需要多年的學習。如果你嘗試用編寫C 的方式寫C的代碼，或者用C的方式編寫C 的代碼，那感覺一定很糟糕。即便你懂C，也不一定會C ，反之亦然，懂C 也不一定會用C編程。
那麼，我們是否應該停止說C/C ，為這兩個不幸的命名而感到悲哀嗎？也不至於。
儘管C 的設計理念與C不一樣，但是C 仍然是C的超集。也就是說，你可以在C 轉換單元中包含C的頭文件，這樣依然可以通過編譯。而這正是造成混亂的地方。
C 不是C的擴展，它是由不同的委員會、不同的人獨立設計的標準。從邏輯上講，喜歡C 理念的人會參與C 社區以及C 標準化的過程，而其他人可能會嘗試參與C。無論是C的委員會還是C 委員會，他們表達意圖和方向的方式只能通過各自的最終產品：標準；而標準是眾多投票的成果。
然而，編譯器很難知道它正在處理的是C頭文件還是C 頭文件。
extern 「C」 標記並沒有得到廣泛一致的使用，而且它只能影響修飾，而不會影響語法或語義。頭文件僅對預處理器有影響，對於C 編譯器而言，所有內容都是C 轉換單元，因此也就是C 。然而，人們依然會在C 中包含C頭文件，並期望它「正常工作」，而大多數時候也確實可以正常工作。
那麼，我們不禁想問：
由不同地方的、不同的人開發的C 代碼如何保持C的兼容性？
恐怕很難。
最近，一位同事讓我想起了康威定律：
"設計系統的架構受制於產生這些設計的組織的溝通結構。"
根據這個邏輯，如果兩個委員不互相合作，則他們創造的語言也不會互通。
C 維護了一個與C及其標準庫的不兼容列表。然而該列表似乎並未反映出許多C11和C18中添加、但在C 中不合法的功能。更清晰的介紹請參見這個維基本科頁面（https://en.wikipedia.org/wiki/Compatibility_of_C_and_C++）。
然而，僅僅列出兩種語言之間的不兼容性，並不足以衡量二者的不兼容性。
那些存在於C 標準庫中但主要聲明來自C的函數，很難聲明成constexpr，更難聲明成noexcept。C的兼容性會導致性能成本，而C函數是優化的障礙。
許多C的結構在C 中都是有效的，但無法通過代碼審查（如NULL、longjmp、malloc、構造/析構函數、free、C風格的類型強制轉換等）。
在C看來，這些慣用寫法可能問題不大，但在C 中可不行。C 具有更強大的類型系統，不幸的是，C的慣用寫法在這個類型系統中鑿了一個洞，因此實現C的兼容性需要在安全性方面付出代價。
別誤會，C 仍然關心C的兼容性，某種程度上。然而，有趣的是C也很關心C ，某種程度上。實話實說，C對C 的關心程度可能高於C 對C的關心。看來，每個委員會還是在乎另一個委員會的工作。但我們很不情願。
C 知道，許多基礎庫都是用C編寫的，不僅包括libc，而且還有zip、png、curl、openssl（！）以及許多其他庫，無數的C 項目都在使用這些庫。C 不能破壞這些兼容性。
但是最近，尤其是在過去的十年中，C 的規模已遠遠超過C。C 擁有更多的用戶，並且社區更加活躍。也許這就是為什麼如今C 委員會的規模是C委員會的10倍以上。
C 是不可忽視的力量，因此C委員會必須考慮不破壞C 兼容性。如果非要說一個標準追隨另一個標準對話，那麼如今C 是領頭者，而C是追隨者。
現在，C 處於穩定的三年周期中，無論是風雨還是烈日，抑或是致命的新疫情。而C每十年左右才發布一次主版本。不過這也很合理，因為作為一種較低級的語言，C不需要發展得那麼快。
C語言的環境也與C 完全不同。C多用於平台，更多地用於編譯器。每個人（甚至他們的狗狗）都會編寫C編譯器，因為該語言的特性集很小，所以任何人都可以編寫C編譯器。而C 委員會真正考慮的實現只有四種，而且在每次會議上這四種實現都會出現。所以，C語言中的許多功能都是與實現有關的，或者是可選支持的，這樣各種編譯器不需要做太多努力就可以聲稱自己遵從了標準，據說這樣委員會的人會比較高興。
如今，C 更加側重於可移植性，而不是實現的自由。這又是一個理念的不同。
因此，你的提議破壞了C的兼容性
我提議的P2178的一部分理論上會影響與C的兼容性。這樣的話所有方案都不會令人滿意。
有人可能會說，你可以先向C委員會提議你的新特性。這意味著需要召開更多會議。C會議的嚴格出席規則可能導致你無法參加會議，這就將那些不願意花上數千美元成為ISO會員的個人拒之門外。這是因為C委員會必須遵守ISO的規則。
而且，如果新的標準剛剛發布，那麼可能還需要等待十年時間，你的提案才會被考慮。最重要的是，如果C委員不理解或不在乎你正在努力解決的問題，那麼你的提案就石沉大海了。或者他們可能沒有精力來處理這個問題。而且，可能你也沒有精力來處理C。畢竟，你的本意是要改進C 。實際上，哪怕會議上無人反對你的提議（儘管不太可能發生），如果有人讓你先去跟C委員會的人討論，就等於給你的提議判了死刑。
另一種可能的情況是，C委員會接受與C 中存在的版本略有不同的版本。true只能做一個宏來實現。char16_t需要通過typedef。char32_t不一定是UTF-32。static_assert對應的是 _Static_assert。
這類的情況還有很多，我們應該責備C嗎？可能不應該。他們的委員會只是在儘力將C語言做好。反之亦然。在C 20中，指定的初始化器就受到了C的啟發，但採取了略微不同的規則，因為如果完全一樣的話就不符合C 的初始化規則。
對於這個問題，我也有責任。C有VLA。如果當時我在，我一定會反對在標準C 中採用它，因為它導致了太多安全性問題。我也會堅決反對將_Generic添加到C 中的提議。也許_Generic的目的是減少由於缺乏模板或缺乏重載而導致的問題，但是C 有這兩個功能，從我的角度來看，_Generic並不適合我想像中的C 。
這兩個委員會似乎對於對方語言的關心程度也不一樣。有時我們會遇到兼容性非常好的情況（std::complex），有時完全不在乎兼容性（靜態數組參數）。
這沒有辦法。別忘了每個委員會都是一群人，他們在不同的時間、不同的地點投票，而試圖控制結果會導致投票毫無意義。將這些人放在同一個房間也不現實。ISO可能會反對，參與者的不平衡會導致C的人處於極大的劣勢。
C的兼容性不重要
如果你是C開發人員，那麼肯定會把C視為一種簡潔的編程語言。但對於我們其他人而言，C的印象完全不同。
C是通用的、跨語言的膠水，可以將一切緊密地結合在一起。
對於C 用戶而言，C就是他們的API。從這一點來看，C的價值在於其簡單性。請記住，C 關心的那一部分C是出現在介面（頭文件）中的C。我們關心的是聲明，而不是定義。C 需要調用C庫中的函數（Python、Fortran、Rust、D、Java等語言也一樣，在所有情況下都可以在介面邊界使用C）。
因此，C是一種介面定義語言。向C添加的內容越多，定義介面就越困難。這些介面隨著時間的推移保持穩定的可能性較小。
那麼，C 中缺少是否重要？可能並不重要，因為這不太可能出現在公共介面中。
如今大家都在談論C
過去，C的兼容性是C 的一大賣點。但如今，每個人（甚至他們的金魚）都懂C。Rust可以調用C函數，Python、Java、一切語言都可以！甚至怪異的Javascript都可以在WebAssemby中調用C函數。
但是在這些語言中，介面是顯式的。該語言提供的工具可以公開特定的C聲明。當然，這比較麻煩。但這可以讓介面非常非常清晰。而且還是有界的。例如，在rust中，調用C函數並不會迫使Rust犧牲某些設計來容納C子集。實際上C是被包含進去的。
編譯器資源管理器
除非C的ABI發生變化，否則這段代碼可以一直正常運行。而且Rust/C的邊界非常清晰、不言自明。
因此，C 可能是為C兼容性付出最多的語言。
更糟糕的是，打開任何C的頭文件，你很快就會發現一堆#ifdef __cplusplus。沒錯，C 的兼容性往往需要大量C開發人員的工作。兼容性一直是海市蜃樓。很多人都知道我的這條推文：
我們該何去何從？
我認為兩個委員會都在嘗試更多地溝通。他們計劃明年在波特蘭召開會議（儘管這個計劃可能會變）。溝通是一件好事。
但是雞同鴨講的溝通效果會非常有限。兩種語言的設計支柱可能都不協調。我會努力建議提供一個模板。但是首先我得吐槽C語言沒有模塊、沒有命名空間，以及整個宏是什麼玩意兒。
也許可以將C 能接受的C子集約束在C99上？也許兩種語言都需要找到一個共同的子集並獨立地發展？也許extern C需要影響解析。如果C 經歷了多個時代，那麼C可能是其中之一。
也許我們需要接受將C作為C 的子集，但唯一的方法是將WG14融入到WG21中。
現狀可能不會改變。C 可能永遠也無法從自己的起源中解脫，而C可能永遠都要與那些頂著C語言之名的骯髒特性戰鬥。
原文：https://cor3ntin.github.io/posts/c/
本文為 CSDN 翻譯，轉載請註明來源出處。
