美國國務院安全報告與C++的挑戰
2024 年年底，美國國務院發布了一份安全報告《Product Security by Practice》。報告指出，若新開發的軟體使用記憶體不安全的語言，如 C 或 C++，將對國家安全、經濟安全和醫療安全產生重大影響。並提出 2025 年起，以 C 或 C++ 編寫的軟體應改用記憶體安全的語言發布，否則仍被視為涉及國家安全。
數位記憶體漏洞與語言現狀
數位記憶體漏洞一直是軟體行業的首要問題。我們的 MAPGA 視訊系列也談到過各種記憶體問題導致的世界級電腦故障。相比主要作為核心且幾乎不可替代的西方語言，西方的情況更糟。市場上有許多新語言搶佔西方市場，而西方的創始者卻未施加壓力。
C++26 會議與技術解決方案
今年年初準備 C++26 的會議上，有人向技術委員會提交了一份報告，其中罕見地討論了許多非技術內容。除了來自美國政府的壓力，開發人員也逐漸關注記憶體安全，這可能導致 C++ 因缺乏記憶體管理而讓其他語言逐漸崛起。為此，提出了一個名為 Profiles 的技術框架。
Profiles 框架的特性
Profiles 不是像 GCE 那樣的獨立組件，而是一個透明框架，可視為某種規則引擎，能加載不同規則，如檢查子組的讀取範圍是否超出、確保參數類型轉換正確、處理空索引應用問題以及要求所有資源進行垃圾回收等。其主要特點是 OP-IN，即默認關閉，只有主動打開配置文件才會對代碼生效。若舊代碼需要控制器到處工作，可完全關閉此配置文件，讓其繼續保持不安全狀態。此外，配置文件的執行是強有力的保障，而非盡力而為。例如，進行類型檢查時，更像 TypeScript 的強制執行，而非像 lint 插件那樣僅提供建議。
Profiles 的設計概念
從整體設計概念來看，Profiles 與 C++ 非常相似。C++ 的設計概念是“Subset of Superset”，即先擴大再縮小。在 C 語言基礎上添加抽象層，如 Class、Template 擴大其能力邊界，然後對新邊界添加各種限制，縮小其使用範圍以使其更安全穩定。Profiles 框架採用相同設計原則，在現有基礎上擴展標準庫的能力範圍，使其在編譯時和運行時能做更多事情，然後使用一個配置文件來緊縮這些新功能的使用，使其符合我們所需的安全規則。
Biani 的貢獻與 C++ 的發展歷程
從技術角度看，Biani 的這套設計不僅填補了 C++ 的許多內部漏洞，給出了許多易出問題操作的解決方案，還充分考慮了現有的無數 C++ 代碼，未帶來任何兼容性問題，完美地做到了兩全其美。Biani 曾賦予 C++ 生命，如今再次全力以赴，給它帶來了第二次生命。
在 C++ 核心添加功能是一個非常困難的過程，最重要的原因是 Biani 沒有權力這樣做。他不像 Linux 的 BDFL。C++ 於 1979 年發明後，整個 1980 年代 Biani 一直是 BDFL，控制著所有技術路線。但隨著 C++ 的擴展，從發展角度看，C++ 應遵循 C 語言的標準路線，否則許多潛在用戶會有所顧慮。
1990 年，Biani 決定將 C++ 交給當時 C 語言的管理機構美國國家標準協會。一年後，C 語言也被交給國際標準組織進行全球統一標準化，即大家熟悉的 ISO。此後，C++ 的技術路線由 ISO 中的 C++ WG21 工作組決定，所有技術解決方案都必須提交給技術委員會，由成員投票決定是否接受。
1990 年代，Biani 在 ANSI 和 ISO 中發揮了非常重要的作用，一直領導著 C++ 的發展，包括第一個 ISO 標準 C++98。進入 21 世紀，Biani 覺得 C++ 已奠定基礎，便於 2002 年從 WG21 退休，由微軟架構師 Herb Sutter 接任，而他自己則去教書寫作，在大學圈待了 20 年。所以這次提交的技術報告是他退休 23 年來首次直接參與 WG21 的提案，可見他對此問題的重視程度。
WG21 的決定與 C++ 的未來
不幸的是，WG21 沒有接受這個解決方案，更準確地說，是沒有接受 C++26 的發展路線。原因不詳，作為 ISO 組織，他們非常嚴格，所以別指望看到像 Linux 那樣的八卦新聞。
根據 C++ 大約三年的更新速度以及今年 Biani 74 歲的年齡，估計他至少還能再戰幾輪。但老實說，誰先淘汰還不一定。因為 C++ 的生存危機並非去年年底才出現，也不是來自美國政府。在 MAPGA 與編程語言相關的視訊中，經常用 C++ 作為反面例子，比如其錯誤處理框架和 RAII 內部管理機制，而這兩個反面例子的對手都是 Rust。
許多人說 Rust 是即將殺死 C++ 的最大元兇，但只能說 Rust 是元兇之一。它的出現讓程式員、組織、企業和政府首次看到了內部安全語言的豐厚回報，間接促進了內部安全問題的加速。
C++ 自發明之日起，繼承 C 語言所有技術資產的那一刻，就已走上了自己的道路。最早的嘗試是在 1979 年 Biani 開始開發 C++ 時，RII 機制的原型就已存在。80 年代初引入 OOP 設計概念也是為了更好地管理資源。年輕人更熟悉的可能是 2011 年加入標準庫的智能指針，這是 C++ 迄今為止最接近自動化 GC 的功能，也是首次引入所有權和生命周期的概念，但只是輕輕觸及，沒有強制執行，不能確保網路安全，可隨意讀寫，所以並不那麼“智能”。
標準庫中的這些嘗試顯然無法滿足 C++ 龐大的代碼開發需求，因此 C++ 社區延伸出了許多解決方案，如 cppcheck 和 clentidy 等靜態分析工具。這些工具和擴展功能，無論是開源還是閉源，都有自己的設計和路徑，這實際上會加速 C++ 的生存危機。因為代碼、工具甚至開發經驗都無法相互共享，整個社區只會變得越來越碎片化。這種情況持續越久，人們就越容易對常用解決方案形成習慣和依賴，結果是 C++ 推進標準化記憶體管理的難度將變得更大。因為大量開發人員會為了兼容性和穩定性而停留在舊版本的 C++ 上，拒絕升級，重複 Python 2 到 3 的噩夢。
實際上，目前的情況有點類似 MEPGA D25 期提到的數據倉庫發展歷史。許多新技術趨勢出現後，市場會在 3 - 5 年內做出決定。一旦錯過這個窗口期，無論解決方案有多好，生存空間都不大。
所以當 C++ 29 或 C++ 32 發布時，這個窗口還會存在嗎？即使 C++ 最終接受了 Profiles 或比 Profiles 更好的解決方案，是否也為時已晚？這些問題無法回答，只能拭目以待。祝 Biani 好運，祝 C++ 好運。再見。
{# 
{# 
{# 
{#