C語言與C++相愛相殺，居然持續了40年...

70年代初，貝爾實驗室建立了C語言，它是開發UNIX的副產品。很快C就成爲了最受歡迎的編程語言之一。可是對於BjarneStroustrup來講，C的表達能力還不夠。因而，他在1983年的博士論文中擴展了C語言。

因而，支持類的C語言誕生了。

當時，BjarneStroustrup明白編程語言有許多組成部分，除了語言自己，還有編譯器、連接器和各類庫。提供熟悉的工具備助於語言被普遍接受。在這種歷史背景下，在C++語言的基礎上開發C++也是有道理的。

40年後，C和C++都在行業中獲得了普遍使用。可是，互聯網上的C開發人員認爲C++是有史以來最糟糕的人類發明，而許多C++開發人員則但願有朝一日C語言灰飛煙滅。

 

一、究竟發生了什麼事？

從表面上看，C和C++均可以知足相同的用例：高性能、肯定性、原生但可移植的代碼，可用於最普遍的硬件和應用程序。

雖然C是一門高級語言，但它更接近彙編。

而C++，從誕生第一天開始就充斥了各類奇怪的東西。例如析構函數這個黑魔法。自做主張的編譯器。儘管很早C++就有了類型推斷功能，可是80年代中期的開發人員還沒法接受這個概念，所以BjarneStroustrup不得不刪除了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++中不合法的功能。

然而，僅僅列出兩種語言之間的不兼容性，並不足以衡量兩者的不兼容性。

那些存在於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是被包含進去的。

modconfinment{usestd::os::raw::{c_char};extern"C"{pubfnputs(txt:*constc_char);}}pubfnmain(){unsafe{confinment::puts(std::ffi::CString::new("Hello,world!").expect("failed!").as_ptr());}}

六、編譯器資源管理器

除非C的ABI發生變化，不然這段代碼能夠一直正常運行。並且Rust/C的邊界很是清晰、不言自明。

所以，C++多是爲C兼容性付出最多的語言。

更糟糕的是，打開任何C的頭文件，你很快就會發現一堆#ifdef__cplusplus。沒錯，C++的兼容性每每須要大量C開發人員的工做。兼容性一直是海市蜃樓。不少人都知道個人這條推文：

 

七、咱們該何去何從？

我認爲兩個委員會都在嘗試更多地溝通。由於溝通是一件好事。

可是雞同鴨講的溝通效果會很是有限。兩種語言的設計支柱可能都不協調。我會努力建議提供一個模板。可是首先我得吐槽C語言沒有模塊、沒有命名空間，以及整個宏是什麼玩意兒。

也許能夠將C++能接受的C子集約束在C99上？也許兩種語言都須要找到一個共同的子集並獨立地發展？也許externC須要影響解析。若是C++經歷了多個時代，那麼C多是其中之一。

也許咱們須要接受將C做爲C++的子集，但惟一的方法是將WG14融入到WG21中。

現狀可能不會改變。C++可能永遠也沒法從本身的起源中解脫，而C可能永遠都要與那些頂着C語言之名的骯髒特性戰鬥。

 

最後，若是你也想成爲程序員，想要快速掌握編程，趕忙加入學習企鵝圈子！

裏面有資深專業軟件開發工程師，在線解答你的全部疑惑~編程語言入門「so easy」

編程學習書籍：

 

編程學習視頻：