許多C++開發(fā)人員則希望C語言灰飛煙滅？！

70年代初，貝爾實(shí)驗(yàn)室創(chuàng)建了C語言，它是開發(fā)UNIX的副產(chǎn)品。很快C就成為了最受歡迎的編程語言之一。但是對(duì)于Bjarne Stroustrup來說，C的表達(dá)能力還不夠。于是，他在1983年的博士論文中擴(kuò)展了C語言。 于是，支持類的C語言誕生了。 當(dāng)時(shí)，Bjarne Stroustrup明白編程語言有許多組成部分，除了語言本身，還有編譯器、鏈接器和各種庫。提供熟悉的工具有助于語言被廣泛接受。在這種歷史背景下，在C語言的基礎(chǔ)上開發(fā)C++也是有道理的。 40年后，C和C++都在行業(yè)中得到了廣泛使用。但是，互聯(lián)網(wǎng)上的C開發(fā)人員認(rèn)為C++是有史以來最糟糕的人類發(fā)明，而許多C++開發(fā)人員則希望有朝一日C語言灰飛煙滅。

1、究竟發(fā)生了什么事？

從表面上看，C和C++都可以滿足相同的用例：高性能、確定性、原生但可移植的代碼，可用于最廣泛的硬件和應(yīng)用程序。

但是，更讓C自豪的是它是一門低級(jí)語言，更接近匯編。 而C++，從誕生第一天開始就充斥了各種奇怪的東西。例如析構(gòu)函數(shù)這個(gè)黑魔法。自作主張的編譯器。盡管很早C++就有了類型推斷功能，但是80年代中期的開發(fā)人員還無法接受這個(gè)概念，因此Bjarne Stroustrup不得不刪除了auto，直到C++ 11又重新添加回來。

從那以后，C++就不斷加入各種工具來實(shí)現(xiàn)抽象。很難說C++是一種低級(jí)語言還是高級(jí)語言。從設(shè)計(jì)目的上來說，C++兩者都是。但是在不犧牲性能的情況下，建立高級(jí)抽象是很困難的。于是C++引入了各種工具來實(shí)現(xiàn)constexpr、move語義、模板和不斷增長(zhǎng)的標(biāo)準(zhǔn)庫。 從根本上講，我認(rèn)為C信任開發(fā)人員，而C++信任編譯器。這是一個(gè)巨大的差異，單憑“兩者的原生類型相同”、“while循環(huán)的語法相同”等簡(jiǎn)單一致是無法掩蓋的。

C++開發(fā)人員將有這些問題歸咎于C，而C開發(fā)人員則認(rèn)為C++過于瘋狂。我覺得站在C的角度看C++，這種說法也很正確。作為C的超集，C++確實(shí)很瘋狂。一個(gè)經(jīng)驗(yàn)豐富的C開發(fā)人員面對(duì)C++可能沒有熟悉的感覺。C++不是C，這就足以引發(fā)互聯(lián)網(wǎng)上的激烈爭(zhēng)論。 然而，雖然我不喜歡C，但也沒有權(quán)利取笑C。盡管我有一定的C++經(jīng)驗(yàn)，但用C編寫過的代碼少之又少，而且肯定是很糟糕的代碼。好的編程語言包括良好的實(shí)踐、模式、慣用寫法，這些都需要多年的學(xué)習(xí)。如果你嘗試用編寫C++的方式寫C的代碼，或者用C的方式編寫C++的代碼，那感覺一定很糟糕。即便你懂C，也不一定會(huì)C++，反之亦然，懂C++也不一定會(huì)用C編程。 那么，我們是否應(yīng)該停止說C/C++，為這兩個(gè)不幸的命名而感到悲哀嗎？也不至于。

盡管C++的設(shè)計(jì)理念與C不一樣，但是C++仍然是C的超集。也就是說，你可以在C++轉(zhuǎn)換單元中包含C的頭文件，這樣依然可以通過編譯。而這正是造成混亂的地方。

C++不是C的擴(kuò)展，它是由不同的委員會(huì)、不同的人獨(dú)立設(shè)計(jì)的標(biāo)準(zhǔn)。從邏輯上講，喜歡C++理念的人會(huì)參與C++社區(qū)以及C++標(biāo)準(zhǔn)化的過程，而其他人可能會(huì)嘗試參與C。無論是C的委員會(huì)還是C++委員會(huì)，他們表達(dá)意圖和方向的方式只能通過各自的最終產(chǎn)品：標(biāo)準(zhǔn)；而標(biāo)準(zhǔn)是眾多投票的成果。 然而，編譯器很難知道它正在處理的是C頭文件還是C++頭文件。 extern “C” 標(biāo)記并沒有得到廣泛一致的使用，而且它只能影響修飾，而不會(huì)影響語法或語義。頭文件僅對(duì)預(yù)處理器有影響，對(duì)于C++編譯器而言，所有內(nèi)容都是C++轉(zhuǎn)換單元，因此也就是C++。然而，人們依然會(huì)在C++中包含C頭文件，并期望它“正常工作”，而大多數(shù)時(shí)候也確實(shí)可以正常工作。

那么，我們不禁想問：

2、由不同地方的、不同的人開發(fā)的C++代碼如何保持C的兼容性？

恐怕很難。 最近，一位同事讓我想起了康威定律： "設(shè)計(jì)系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計(jì)的組織的溝通結(jié)構(gòu)。" 根據(jù)這個(gè)邏輯，如果兩個(gè)委員不互相合作，則他們創(chuàng)造的語言也不會(huì)互通。 C++維護(hù)了一個(gè)與C及其標(biāo)準(zhǔn)庫的不兼容列表。然而該列表似乎并未反映出許多C11和C18中添加、但在C++中不合法的功能。更清晰的介紹請(qǐng)參見這個(gè)維基本科頁面（https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B）。 然而，僅僅列出兩種語言之間的不兼容性，并不足以衡量二者的不兼容性。 那些存在于C++標(biāo)準(zhǔn)庫中但主要聲明來自C的函數(shù)，很難聲明成constexpr，更難聲明成noexcept。C的兼容性會(huì)導(dǎo)致性能成本，而C函數(shù)是優(yōu)化的障礙。

許多C的結(jié)構(gòu)在C++中都是有效的，但無法通過代碼審查（如NULL、longjmp、malloc、構(gòu)造/析構(gòu)函數(shù)、free、C風(fēng)格的類型強(qiáng)制轉(zhuǎn)換等）。 在C看來，這些慣用寫法可能問題不大，但在C++中可不行。C++具有更強(qiáng)大的類型系統(tǒng)，不幸的是，C的慣用寫法在這個(gè)類型系統(tǒng)中鑿了一個(gè)洞，因此實(shí)現(xiàn)C的兼容性需要在安全性方面付出代價(jià)。 別誤會(huì)，C++仍然關(guān)心C的兼容性，某種程度上。然而，有趣的是C也很關(guān)心C++，某種程度上。實(shí)話實(shí)說，C對(duì)C++的關(guān)心程度可能高于C++對(duì)C的關(guān)心?？磥?，每個(gè)委員會(huì)還是在乎另一個(gè)委員會(huì)的工作。但我們很不情愿。

C++知道，許多基礎(chǔ)庫都是用C編寫的，不僅包括libc，而且還有zip、png、curl、openssl（?。┮约霸S多其他庫，無數(shù)的C++項(xiàng)目都在使用這些庫。C++不能破壞這些兼容性。 但是最近，尤其是在過去的十年中，C++的規(guī)模已遠(yuǎn)遠(yuǎn)超過C。C++擁有更多的用戶，并且社區(qū)更加活躍。也許這就是為什么如今C++委員會(huì)的規(guī)模是C委員會(huì)的10倍以上。 C++是不可忽視的力量，因此C委員會(huì)必須考慮不破壞C++兼容性。如果非要說一個(gè)標(biāo)準(zhǔn)追隨另一個(gè)標(biāo)準(zhǔn)對(duì)話，那么如今C++是領(lǐng)頭者，而C是追隨者。 現(xiàn)在，C++處于穩(wěn)定的三年周期中，無論是風(fēng)雨還是烈日，抑或是致命的新疫情。而C每十年左右才發(fā)布一次主版本。不過這也很合理，因?yàn)樽鳛橐环N較低級(jí)的語言，C不需要發(fā)展得那么快。

C語言的環(huán)境也與C++完全不同。C多用于平臺(tái)，更多地用于編譯器。每個(gè)人（甚至他們的狗狗）都會(huì)編寫C編譯器，因?yàn)樵撜Z言的特性集很小，所以任何人都可以編寫C編譯器。而C++委員會(huì)真正考慮的實(shí)現(xiàn)只有四種，而且在每次會(huì)議上這四種實(shí)現(xiàn)都會(huì)出現(xiàn)。所以，C語言中的許多功能都是與實(shí)現(xiàn)有關(guān)的，或者是可選支持的，這樣各種編譯器不需要做太多努力就可以聲稱自己遵從了標(biāo)準(zhǔn)，據(jù)說這樣委員會(huì)的人會(huì)比較高興。 如今，C++更加側(cè)重于可移植性，而不是實(shí)現(xiàn)的自由。這又是一個(gè)理念的不同。

3、因此，你的提議破壞了C的兼容性

我提議的P2178的一部分理論上會(huì)影響與C的兼容性。這樣的話所有方案都不會(huì)令人滿意。 有人可能會(huì)說，你可以先向C委員會(huì)提議你的新特性。這意味著需要召開更多會(huì)議。C會(huì)議的嚴(yán)格出席規(guī)則可能導(dǎo)致你無法參加會(huì)議，這就將那些不愿意花上數(shù)千美元成為ISO會(huì)員的個(gè)人拒之門外。這是因?yàn)镃委員會(huì)必須遵守ISO的規(guī)則。

而且，如果新的標(biāo)準(zhǔn)剛剛發(fā)布，那么可能還需要等待十年時(shí)間，你的提案才會(huì)被考慮。最重要的是，如果C委員不理解或不在乎你正在努力解決的問題，那么你的提案就石沉大海了?；蛘咚麄兛赡軟]有精力來處理這個(gè)問題。而且，可能你也沒有精力來處理C。畢竟，你的本意是要改進(jìn)C++。實(shí)際上，哪怕會(huì)議上無人反對(duì)你的提議（盡管不太可能發(fā)生），如果有人讓你先去跟C委員會(huì)的人討論，就等于給你的提議判了死刑。

另一種可能的情況是，C委員會(huì)接受與C++中存在的版本略有不同的版本。true只能做一個(gè)宏來實(shí)現(xiàn)。char16_t需要通過typedef。char32_t不一定是UTF-32。static_assert對(duì)應(yīng)的是 _Static_assert。 這類的情況還有很多，我們應(yīng)該責(zé)備C嗎？可能不應(yīng)該。他們的委員會(huì)只是在盡力將C語言做好。反之亦然。在C++20中，指定的初始化器就受到了C的啟發(fā)，但采取了略微不同的規(guī)則，因?yàn)槿绻耆粯拥脑捑筒环螩++的初始化規(guī)則。 對(duì)于這個(gè)問題，我也有責(zé)任。C有VLA。如果當(dāng)時(shí)我在，我一定會(huì)反對(duì)在標(biāo)準(zhǔn)C++中采用它，因?yàn)樗鼘?dǎo)致了太多安全性問題。我也會(huì)堅(jiān)決反對(duì)將_Generic添加到C++中的提議。也許_Generic的目的是減少由于缺乏模板或缺乏重載而導(dǎo)致的問題，但是C++有這兩個(gè)功能，從我的角度來看，_Generic并不適合我想象中的C++。 這兩個(gè)委員會(huì)似乎對(duì)于對(duì)方語言的關(guān)心程度也不一樣。有時(shí)我們會(huì)遇到兼容性非常好的情況（std::complex），有時(shí)完全不在乎兼容性（靜態(tài)數(shù)組參數(shù)）。 這沒有辦法。別忘了每個(gè)委員會(huì)都是一群人，他們?cè)诓煌臅r(shí)間、不同的地點(diǎn)投票，而試圖控制結(jié)果會(huì)導(dǎo)致投票毫無意義。將這些人放在同一個(gè)房間也不現(xiàn)實(shí)。ISO可能會(huì)反對(duì)，參與者的不平衡會(huì)導(dǎo)致C的人處于極大的劣勢(shì)。

4、C的兼容性不重要

如果你是C開發(fā)人員，那么肯定會(huì)把C視為一種簡(jiǎn)潔的編程語言。但對(duì)于我們其他人而言，C的印象完全不同。 C是通用的、跨語言的膠水，可以將一切緊密地結(jié)合在一起。 對(duì)于C++用戶而言，C就是他們的API。從這一點(diǎn)來看，C的價(jià)值在于其簡(jiǎn)單性。請(qǐng)記住，C++關(guān)心的那一部分C是出現(xiàn)在接口（頭文件）中的C。我們關(guān)心的是聲明，而不是定義。C++需要調(diào)用C庫中的函數(shù)（Python、Fortran、Rust、D、Java等語言也一樣，在所有情況下都可以在接口邊界使用C）。 因此，C是一種接口定義語言。向C添加的內(nèi)容越多，定義接口就越困難。這些接口隨著時(shí)間的推移保持穩(wěn)定的可能性較小。 那么，C++中缺少是否重要？可能并不重要，因?yàn)檫@不太可能出現(xiàn)在公共接口中。

5、如今大家都在談?wù)揅

過去，C的兼容性是C++的一大賣點(diǎn)。但如今，每個(gè)人（甚至他們的金魚）都懂C。Rust可以調(diào)用C函數(shù)，Python、Java、一切語言都可以！甚至怪異的Javascript都可以在WebAssemby中調(diào)用C函數(shù)。 但是在這些語言中，接口是顯式的。該語言提供的工具可以公開特定的C聲明。當(dāng)然，這比較麻煩。但這可以讓接口非常非常清晰。而且還是有界的。例如，在rust中，調(diào)用C函數(shù)并不會(huì)迫使Rust犧牲某些設(shè)計(jì)來容納C子集。實(shí)際上C是被包含進(jìn)去的。

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

6、編譯器資源管理器

除非C的ABI發(fā)生變化，否則這段代碼可以一直正常運(yùn)行。而且Rust/C的邊界非常清晰、不言自明。 因此，C++可能是為C兼容性付出最多的語言。 更糟糕的是，打開任何C的頭文件，你很快就會(huì)發(fā)現(xiàn)一堆#ifdef __cplusplus。沒錯(cuò)，C++的兼容性往往需要大量C開發(fā)人員的工作。兼容性一直是海市蜃樓。很多人都知道我的這條推文：

7、我們?cè)摵稳ズ螐模?/p>

我認(rèn)為兩個(gè)委員會(huì)都在嘗試更多地溝通。他們計(jì)劃明年在波特蘭召開會(huì)議（盡管這個(gè)計(jì)劃可能會(huì)變）。溝通是一件好事。 但是雞同鴨講的溝通效果會(huì)非常有限。兩種語言的設(shè)計(jì)支柱可能都不協(xié)調(diào)。我會(huì)努力建議提供一個(gè)模板。但是首先我得吐槽C語言沒有模塊、沒有命名空間，以及整個(gè)宏是什么玩意兒。 也許可以將C++能接受的C子集約束在C99上？也許兩種語言都需要找到一個(gè)共同的子集并獨(dú)立地發(fā)展？也許extern C需要影響解析。如果C++經(jīng)歷了多個(gè)時(shí)代，那么C可能是其中之一。

也許我們需要接受將C作為C++的子集，但唯一的方法是將WG14融入到WG21中。 現(xiàn)狀可能不會(huì)改變。C++可能永遠(yuǎn)也無法從自己的起源中解脫，而C可能永遠(yuǎn)都要與那些頂著C語言之名的骯臟特性戰(zhàn)斗。

-END-

來源 | CSDN

原文標(biāo)題：C語言與C++40 年的愛恨情仇！

文章出處：【微信公眾號(hào)：嵌入式ARM】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。