70年代初，貝爾實驗室創建了C語言，它是開發UNIX的副產品，很快C就成為了最受歡迎的編程語言之一，但是對于Bjarne Stroustrup來說，C的表達能力還不夠，于是，他在1983年的博士論文中擴展了C語言，
于是，支持類的C語言誕生了，
當時，Bjarne Stroustrup明白編程語言有許多組成部分，除了語言本身，還有編譯器、聯結器和各種庫，提供熟悉的工具有助于語言被廣泛接受，在這種歷史背景下，在C語言的基礎上開發C++也是有道理的，
40年后，C和C++都在行業中得到了廣泛使用，但是，互聯網上的C開發人員認為C++是有史以來最糟糕的人類發明，而許多C++開發人員則希望有朝一日C語言灰飛煙滅，
1、究竟發生了什么事？
從表面上看，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++頭檔案，
extern “C” 標記并沒有得到廣泛一致的使用，而且它只能影響修飾，而不會影響語法或語意，頭檔案僅對前處理器有影響，對于C++編譯器而言，所有內容都是C++轉換單元，因此也就是C++，然而，人們依然會在C++中包含C頭檔案，并期望它“正常作業”，而大多數時候也確實可以正常作業，
那么，我們不禁想問：
2、由不同地方的、不同的人開發的C++代碼如何保持C的兼容性？
恐怕很難，
最近，一位同事讓我想起了康威定律：
"設計系統的架構受制于產生這些設計的組織的溝通結構，"
根據這個邏輯，如果兩個委員不互相合作，則他們創造的語言也不會互通，
C++維護了一個與C及其標準庫的不兼容串列，然而該串列似乎并未反映出許多C11和C18中添加、但在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++更加側重于可移植性，而不是實作的自由，這又是一個理念的不同，
3、C的兼容性不重要
如果你是C開發人員，那么肯定會把C視為一種簡潔的編程語言，但對于我們其他人而言，C的印象完全不同，
C是通用的、跨語言的膠水，可以將一切緊密地結合在一起，
對于C++用戶而言，C就是他們的API，從這一點來看，C的價值在于其簡單性，請記住，C++關心的那一部分C是出現在介面（頭檔案）中的C，我們關心的是宣告，而不是定義，C++需要呼叫C庫中的函式（Python、Fortran、Rust、D、Java等語言也一樣，在所有情況下都可以在介面邊界使用C），
因此，C是一種介面定義語言，向C添加的內容越多，定義介面就越困難，這些介面隨著時間的推移保持穩定的可能性較小，
那么，C++中缺少<threads.h>是否重要？可能并不重要，因為這不太可能出現在公共介面中，
4、如今大家都在談論C
過去，C的兼容性是C++的一大賣點，但如今，每個人（甚至他們的金魚）都懂C，Rust可以呼叫C函式，Python、Java、一切語言都可以！甚至怪異的Javascript都可以在WebAssemby中呼叫C函式，
但是在這些語言中，介面是顯式的，該語言提供的工具可以公開特定的C宣告，當然，這比較麻煩，但這可以讓介面非常非常清晰，而且還是有界的，例如，在rust中，呼叫C函式并不會迫使Rust犧牲某些設計來容納C子集，實際上C是被包含進去的，
mod confinment {
use std::os::raw::{c_char};
extern"C" {
pub fn puts(txt: *const c_char);
}
}
pub fn main() {
unsafe {
confinment::puts(
std::ffi::CString::new("Hello, world!").expect("failed!").as_ptr()
);
}
}
5、編譯器資源管理器
除非C的ABI發生變化，否則這段代碼可以一直正常運行，而且Rust/C的邊界非常清晰、不言自明，
因此，C++可能是為C兼容性付出最多的語言，
更糟糕的是，打開任何C的頭檔案，你很快就會發現一堆#ifdef __cplusplus，沒錯，C++的兼容性往往需要大量C開發人員的作業，兼容性一直是海市蜃樓，
6、我們該何去何從？
我認為兩個委員會都在嘗試更多地溝通，他們計劃明年在波特蘭召開會議（盡管這個計劃可能會變），溝通是一件好事，
但是雞同鴨講的溝通效果會非常有限，
也許可以將C++能接受的C子集約束在C99上？也許兩種語言都需要找到一個共同的子集并獨立地發展？也許extern C需要影響決議，如果C++經歷了多個時代，那么C可能是其中之一，
也許我們需要接受將C作為C++的子集，但唯一的方法是將WG14融入到WG21中，
現狀可能不會改變，C++可能永遠也無法從自己的起源中解脫，而C可能永遠都要與那些頂著C語言之名的骯臟特性戰斗，
看到這里你是不是對C語言/C++又有了一點新的認知呢~
如果你喜歡這篇文章的話，動動小指，點個贊哦~
如果你想學編程，小編推薦一個C語言/C++編程學習基地【點擊進入】！
一個活躍、高逼格、高層次的編程學習殿堂；編程入門只是順帶，思維的提高才有價值！
涉及到了：編程入門、游戲編程、網路編程、Windows編程、Linux編程、Qt界面開發、黑客等等......
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/164777.html
標籤：其他