C++ 兩大派系之爭

C語言與CPP編程

點擊上方“C語言與CPP編程”，選擇“關注/置頂/星標公眾號”
干貨福利，第一時間送達！
最近有小伙伴說沒有收到當天的文章推送，這是因為微信改了推送機制，有一部分小伙伴刷不到當天的文章，一些比較實用的知識和信息，錯過了就是錯過了，建議大家加個星標??，就能第一時間收到推送。

關于 C++ 的未來，近段時間似乎引發(fā)不少的爭論。無論是在 Reddit、HN 上，還是在 C++ 標準委員會的會議上，四處可見這些討論。

1、C++ 的現(xiàn)狀
當前，我們所使用的 C++ 似乎正處于以下局面：
1. C++ 的演進工作組（EWG）剛剛就采納 P3466 R0 達成共識——即，(重新)確認未來 C++ 演進的設計原則：

不允許 ABI（應用二進制接口）中斷，保持與 C 以及早期 C++ 版本的鏈接兼容性。

不引入“病毒式注解”（例如，不支持生命周期注解）。

堅持一組互相矛盾的目標，例如同時要求不破壞 ABI 和零開銷原則。
這無論這是好是壞，都表明 C++ 的發(fā)展方向在進一步鞏固當前的軌跡。

2. 與此同時，一方面，美國政府希望人們停止使用 C++：

美國網絡安全和基礎設施安全局(CISA)

美國國家安全局(NSA)

甚至白宮
截至目前，美國政府的各個部門已經發(fā)布了文件、報告和建議，警告行業(yè)不要使用內存不安全的語言。



3. 各種大型科技公司正在采用 Rust：

微軟顯然正在用 Rust 重寫核心庫：去年 10 月，微軟在 GitHub 中發(fā)布了一系列開發(fā)工具包，讓開發(fā)者可以使用 Rust 語言來編寫 Windows 驅動程序。

谷歌似乎也致力于 Rust：其先是宣布支持使用 Rust 開發(fā) Chromium，同時也開發(fā)一個雙向 C++/Rust 互操作工具。

2019 年，AWS 表示開始在其基礎架構中越來越多地使用 Rust 后，決定贊助 Rust，即 Rust 團隊可以優(yōu)惠租用 AWS 基礎設施以進行語言開發(fā)。

......
說到大型科技公司，近期還有幾件事值得注意：

不久前，ISO C++ 委員會主席 Herb Sutter 在其個人博客宣布，他已經離開了工作 22 年的微軟，正式成為金融公司 Citadel Securities 的一名技術研究員。而 MSVC（Microsoft Visual C+）似乎在實現(xiàn) C++23 功能上進展緩慢，還在向社區(qū)征求優(yōu)先級意見。

臭名昭著的布拉格 ABI 投票事件發(fā)生了（簡而言之：“C++ 23 不會破壞 ABI，將來是否會破壞也尚不明朗�！保�，據(jù)說 Google 大幅減少了參與 C 開發(fā)過程的工作，轉而開始開發(fā)自己的 C++ 后續(xù)語言——Carbon。他們甚至寫了一個文檔，總結他們在嘗試改進 C++ 時遇到的種種困難（https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md）。
4. 社區(qū)中的問題：

之前有很多人分享過自己盡最大努力參與 C++ 標準委員會的過程，但最終卻被消耗殆盡。即使有些功能在 C 中實現(xiàn)了也沒有什么用。

事到如今，模塊功能尚未實現(xiàn)。我們有模塊了嗎？答案是否定的。

相信不少人還記得在 2023 年 CppCon 2023 的演講中，C++ 之父 Bjarne Stroustrup 首次提出了安全配置文件（Safety Profiles）的概念，目的是為 C++ 提供更強的類型和資源安全性，同時盡量避免破壞現(xiàn)有的兼容性。Safety Profiles 的核心是通過一組規(guī)則和工具引導開發(fā)者編寫更安全的代碼，同時允許不同的項目根據(jù)需求選擇適合的安全級別。然而，“安全配置文件”（Safety Profiles）仍處于一種奇怪的狀態(tài)，沒有任何現(xiàn)有實現(xiàn)，它試圖在盡量減少對現(xiàn)有代碼更改的情況下，為現(xiàn)有的 C++ 代碼增加某種程度的安全性。C++ 聯(lián)盟開發(fā)人員 Sean Gaxter（Circle 編譯器的創(chuàng)造者）本人公開反對配置文件，稱 C++ 為“定義不足”的語言。
我不知道你怎么看，但如果我作為一個外行人來看待這一切，C++ 似乎基本上已經分崩離析了，而且似乎很多人已經對 C++ 委員會能夠處理這些問題的能力失去了信心。

2、C++ 的兩大派系
人們似乎正在尋找其他解決方案。
比如說 Google。自從 ABI 投票以來，Google 顯然對“這一標準化流程”失去了信心。這種失望并非針對 C++ 語言本身——Google 自己擁有龐大的 C++ 代碼庫，這門語言對他們來說一直表現(xiàn)出色。然而，他們對 C++ 在多方壓力（如潛在的政府監(jiān)管、其他語言的競爭、大廠對更高性能和安全保障的需求等）下繼續(xù)演進的能力失去了信心。
那么問題出現(xiàn)在哪里？為什么 C++ 不能做出改變呢？
答案其實很簡單。我們可以參考 ISO C++ 委員會主席 Herb Sutter 在其關于配置文件的論文中所說的話：
“我們必須盡量減少對現(xiàn)有代碼的修改需求。根據(jù)幾十年的經驗，對于擁有大型代碼庫的大多數(shù)客戶來說，即便是為了安全原因，也不會因為嚴格性規(guī)則而修改哪怕 1% 的代碼，除非有法規(guī)要求強制執(zhí)行�！�
——Herb Sutter
這很合理，不是嗎？沒人對此感到驚訝。
現(xiàn)在，對比一下 Google 工程師 Chandler Carruth 在 WG21 成員頁面上的簡介：
“我主導了基于 Clang 的 C++ 工具和自動化重構系統(tǒng)的設計，這些工具現(xiàn)在已成為 Clang 項目的一部分……
在 Google 內部，我?guī)ьI團隊將這些基于 Clang 的自動化重構工具擴展到整個代碼庫，超過 1 億行 C++ 代碼。我們可以在 20 分鐘內對整個代碼庫進行分析并應用重構。”

看到了嗎？這里 Chandler Carruth 提到了一個關鍵詞是“自動化工具”。但不只是自動化遷移工具，這只是最顯眼的例子。
兩種 C++ 用戶陣營的對立
實際上，我們看到的是兩種完全不同的 C++ 用戶陣營之間的沖突：

相對現(xiàn)代、有能力的技術公司，它們明白自己的代碼是一種資產。（這并不嚴格限于大科技公司。任何新興的 C++ 初創(chuàng)公司也屬于這一類。）

其他所有人。那些仍在爭論如何縮進代碼的老牌公司，以及年輕工程師試圖說服管理層允許他設置代碼檢查工具的情況。
這兩種用戶之間的關鍵區(qū)別在于：前者能夠相對順利地應對遷移，因為他們能從版本化源碼構建整個 C++ 棧，而后者則仍在使用 1998 年的老舊庫。
這種能力——從版本化源碼構建整個依賴棧（最好還帶有自動化測試）——是兩大陣營之間最重要的分水嶺。
當然，在實踐中，這是一個漸進的過程。我可以想象，要把大公司的代碼庫從可怕的泥球變成半可管理、可構建、經過代碼檢查、適當版本化、稍微不那么可怕的泥球，必須流下多少汗水、淚水、賬單和心血。
事后看來，很容易認為這一切都是不可避免的：像 Google 這樣的公司（使用相對現(xiàn)代的 C++，擁有自動化工具和測試，以及現(xiàn)代基礎設施）的需求與強烈向后兼容的愿望之間存在明顯的脫節(jié)。
大膽地說，單一、無方言且統(tǒng)一的 C++ 的概念似乎已經死多年了。至少，我們有兩種主流風格的 C++：

稍微現(xiàn)代化一點的 C++。一切都可以通過某種專用、干凈且統(tǒng)一的構建流程從版本化的源碼構建，至少比原始 CMake 稍微復雜一些，如果稍微瞇著眼睛看，它就能正常工作。包含一些靜態(tài)分析器、格式化程序、代碼檢查器。任何一種保持代碼庫清潔和現(xiàn)代化是有價值的共識。可能至少是 C++17，帶有`unique_ptr`、`constexpr`、`optional`等特性，但這不是重點。重要的是工具。

傳統(tǒng)的 C++。即任何不符合上述條件的 C++。比如那些存放在中型銀行古老服務器上的 C++。任何依賴于某個完全古老且已編譯代碼塊的 C++，其源碼已經丟失，原作者也無法聯(lián)系。任何部署在寵物類型服務器上的 C++，以至于在其他地方啟動它需要工程師花整整一個月的時間來弄清楚所有隱含的依賴項、配置和環(huán)境變量。這些主要被歸類為成本中心的代碼庫。任何從源碼構建使用的二進制文件都需要按下不止幾個按鈕，或者根本無法構建的代碼。
你會注意到，這兩種文化的分歧不在于 C++ 語言本身，而是工具和是否能從版本化源碼進行干凈、有定義的構建。理想情況下，甚至能夠在不需要記住以前開發(fā)者通常設置的那個標志或環(huán)境變量的情況下進行部署。
例如，Google 的代碼庫是否完全采用“現(xiàn)代” C++ 習慣用法并不是重點。關鍵是工具是否到位，以及是否能夠從源碼構建。
很多人會說工具不是 C++ 標準委員會的責任，這觀點是對的。工具確實不是 C++ 標準委員會的責任，因為 C++ 標準委員會放棄了對它的責任（他們專注于語言規(guī)范，而非具體的實現(xiàn)）。這是設計使然，考慮到遺留負擔很難去責怪他們。C++ 是一個統(tǒng)一不同實現(xiàn)的標準。
話雖如此，如果說 Go 語言有一件事做對了，那就是他們把工具放得很重要。相比之下，C++ 出生于一個比 linter 更古老的時代。C++ 沒有統(tǒng)一的構建系統(tǒng)，也沒有接近統(tǒng)一的包管理系統(tǒng)，語法復雜難以解析（這對工具來說很糟糕），且每次改動都在與 Hyrum 定律作斗爭。
這兩個派系（良好的工具，可以毫不費力地從源碼構建 vs. 差勁的工具，無法從源碼構建）之間存在著巨大的、不斷擴大的裂痕，而且短期內看不到彌合的可能性。
C++ 委員會似乎堅決維護向后兼容性，無論代價如何。
順便說一句，我并不一定反對這一點！向后兼容性對許多人來說非常重要，理由充分。然而，對另一些人而言，這并不重要。這不是誰“對”的問題，而是兩種截然不同、無法調和的立場之間的沖突。
3、造成的后果
這就是為什么配置文件的設計是這樣的：安全配置文件的目的并不是為了解決現(xiàn)代、技術嫻熟的 C++ 公司的需求。它們是為了在不需要對舊代碼進行任何更改的情況下帶來改進。
同樣地，對于模塊也是如此。設計初衷是讓你“只需”以模塊形式導入頭文件，而不會引發(fā)任何向后兼容性問題。
毫無疑問，大家都喜歡那些可以直接引入并在不改動舊代碼的情況下帶來改進的功能。但很明顯，這些功能的設計初衷是為了迎合“傳統(tǒng) C++”的需求。任何需要從傳統(tǒng) C++ 遷移的功能對 C++ 標準委員會來說都是不可行的，因為正如 Herb Sutter 所說，你基本上不能指望人們自己去遷移。
（再次強調，考慮傳統(tǒng) C++ 的需求并不是壞事。這完全是一個合理的決策。）
這一點我始終牢記在心，每當我閱讀 C++ 提案時都會注意：C++ 其實有兩個主要受眾群體。一是現(xiàn)代 C++ 用戶，另一個是傳統(tǒng) C++ 用戶。這兩個陣營對許多問題的看法大相徑庭，且許多提案都是針對其中一個特定群體的需求而撰寫的。
顯然，這導致了許多人無法互相理解，話說不到一塊：盡管許多人以為安全配置文件和 safe C++ 是在解決同樣的問題，實際上它們面向的是完全不同的受眾，解決的是完全不同的問題。
C++ 委員會正試圖阻止這種裂痕進一步擴大。這或許就是為什么 Sean Baxter 撰寫的《 Safe C++》對他們來說毫無意義的原因。這種提案是一種激進且全面的變革，可能會開創(chuàng)一種完全不同的 C++ 編程方式。
當然，也有人提出另一個問題：是否某些 C++ 標準委員會成員只是過于固執(zhí)，抓住各種理由來阻止他們個人在審美上不認可的演進。
這是否屬實，我不便評判，但關于 C++ 標準委員會應用“雙重標準”的說法并非首次聽聞。比如“如果你想讓這個提案被通過，我們要求你提供多個編譯器的完整、可用的實現(xiàn)；但我們仍然愿意支持某些大項目（例如模塊、配置文件），即便這些項目根本沒有任何可用的概念驗證實現(xiàn)�！�
如果真是如此（我無法確證），我無法預測 C++ 還能沿著這條道路走多久，除非最終發(fā)生更為劇烈的分裂。
更不用提，打破 ABI 兼容性可能引發(fā)的巨大麻煩和一系列問題，那簡直就是個無底洞。
4、C++ 未來將何去何從？
面對現(xiàn)代企業(yè)和遺留系統(tǒng)給 C++ 社區(qū)內部帶來兩極分化的趨勢，不少網友看法不一。
來自 Reddit 的用戶 ravixp 表示：
這讓我感同身受，也許是因為我曾親眼看到一個非常大的 C++ 代碼庫在不同層面和不同規(guī)模上，從“遺留”C++逐步過渡到“現(xiàn)代”C++的過程。這種轉換涉及不同團隊以各自的節(jié)奏和時間點推進，跨越了數(shù)十年的開發(fā)周期，至今仍在進行中。而任何新的代碼現(xiàn)代化計劃，都需要面對代碼庫中各部分的現(xiàn)代化水平不一致的問題。
（想象一下試圖對這樣的代碼添加靜態(tài)分析支持：它同時包含了 std::string、C 風格字符串，以及 20 年前 STL 性能較差時團隊自行創(chuàng)建的字符串類型的奇怪中間狀態(tài)！）
關鍵在于，現(xiàn)代化的成本非常高昂。這里提到的“現(xiàn)代”C++不僅僅是用不同的方式編寫代碼，它還包括一整套支持現(xiàn)代化標準的工具體系，這可能需要從零開始構建，還需要一個能夠跟上 C++ 演進的工程團隊。
需要牢記的是，這里的沖突并不是“喜歡遺留 C++”的人與“喜歡現(xiàn)代 C++”的人之間的矛盾，而是“能負擔得起現(xiàn)代 C++”的人與“負擔不起”的人之間的矛盾。C++ 的確需要改變，但真正的問題是：我們集體能夠承受多少變化的成本，以及如何從中獲得最大的價值。
Kronikarz 評價道：
從道德角度來看，我認為這反映了一種分歧：一部分人對 C++ 逐漸變成下一個 COBOL 不以為意，另一部分人則對這一想法感到排斥。
另一位網友 KittensInc 則認為：
遺留 C++ 正在迅速成為一種負擔。美國政府已經意識到，通過做出不同的設計決策，可以完全避免某些類型的漏洞，并正在推動人們減少這些錯誤。我認為，負責管理責任的機構最終會加入這一趨勢只是時間問題。
如果像緩沖區(qū)溢出這樣的漏洞被認為是完全可以預防的，那么從邏輯上講，如果某次黑客攻擊、勒索軟件事件或數(shù)據(jù)泄露的根本原因是緩沖區(qū)溢出，保險公司可能會拒絕賠付。這樣一來，公司可能會要求軟件供應商對其代碼庫進行第三方靜態(tài)分析審計。
于是我們到達了這樣一個節(jié)點：不進行現(xiàn)代化改造的成本變得過高。你要么升級你的代碼庫，要么你的公司走向滅亡。采用現(xiàn)代開發(fā)實踐的企業(yè)只需運行一些簡單的分析工具并完成一些文書工作，而那些沒有任何像樣工具并且背負著數(shù)十年技術債務的公司將陷入嚴重困境。
對此，你怎么看？
作者 | Mond      翻譯 | 屠敏    出品 | CSDN（ID：CSDNnews）分享一個福利分享一個羊毛，最近極客時間出了一個《MySQL底層原理精講》的專欄，目前還在內測階段，主要是看市場反饋來定價，所以現(xiàn)在還是免費階段，等上線了估計就可能收費了。
除此外，附贈前人的MySQL學習筆記，有意掃碼自取

MySQL學習筆記

一次吃透 MySQL 底層原理?? 架構篇、事務篇、索引與鎖篇全覆蓋，掃描下方二維碼自取！



我組建了一些社群一起交流，群里有大牛也有小白，如果你有意可以一起進群交流。

歡迎你添加我的微信，我拉你進技術交流群。此外，我也會經常在微信上分享一些計算機學習經驗以及工作體驗，還有一些內推機會。

加個微信，打開另一扇窗
感謝你的分享，點贊，在看三連