對 C++ 的憂慮？C++ 創始人警告：關於 C++ 的某些未來計劃十分危險

今年早些時候，我們對 Bjarne Stroustrup 進行了採訪。他是 C++ 語言的創始人，摩根士丹利技術部門的董事總經理，美國哥倫比亞大學計算機科學的客座教授。他寫了一封信，請那些關注編程語言進展的人去「想想瓦薩號！」

這句話對於丹麥人來說，毫無疑問，很容易理解。而那些對於 17 世紀的斯堪的納維亞歷史了解不多的人，還需要詳細說明一下。瓦薩號是一艘瑞典軍艦，由國王 Gustavus Adolphus 定做。它是當時波羅的海國家中最強大的軍艦，但在 1628 年 8 月 10 日首航沒幾分鐘之後就沉沒了。

巨大的瓦薩號有一個難以解決的設計缺陷：頭重腳輕，以至於它被一陣狂風刮翻了。通過援引這艘沉船的歷史，Stroustrup 警示了 C++ 所面臨的風險 —— 現在越來越多的特性被添加到了 C++ 中。

我們現在已經發現了好些能導致頭重腳輕的特性。Stroustrup 在他的信中引用了 43 個提議。他認為那些參與 C++ 語言 ISO 標準演進的人（即所謂的 WG21 小組）正在努力推進語言發展，但成員們的努力方向卻並不一致。

在他的信中，他寫道：

分開來看，許多提議都很有道理。但將它們綜合到一起，這些提議是很愚蠢的，將危害 C++ 的未來。

他明確表示，他用瓦薩號作為比喻並不是說他認為不斷提升會帶來毀滅。我們應該吸取瓦薩號的教訓，構建一個堅實的基礎，從錯誤中學習並對新版本做徹底的測試。

在瑞士 拉普斯威爾 Rapperswill 召開 C++ 標準化委員會會議之後，本月早些時候，Stroustrup 接受了 The Register 的採訪，回答了有關 C++ 語言下一步發展方向的幾個問題。（最新版是去年剛發布的 C++17；下一個版本是 C++20，預計於 2020 年發布。）

Register：在您的信件《想想瓦薩號！》中，您寫道：

在 C++11 開始的基礎建設尚未完成，而 C++17 基本沒有在使基礎更加穩固、規範和完整方面做出改善。相反，卻增加了重要介面的複雜度（原文為 surface complexity，直譯「表面複雜度」），讓人們需要學習的特性數量越來越多。C++ 可能在這種不成熟的提議的重壓之下崩潰。我們不應該花費大量的時間為專家級用戶們（比如我們自己）去創建越來越複雜的東西。（還要考慮普通用戶的學習曲線，越複雜的東西越不易普及。）

對新人來說，C++ 過難了嗎？如果是這樣，您認為怎樣的特性讓新人更易理解？

Stroustrup：C++ 的有些東西對於新人來說確實很具有挑戰性。

另一方面而言，C++ 中有些東西對於新人來說，比起 C 或上世紀九十年代的 C++ 更容易理解了。而難點是讓大型社區專註於這些部分，並且幫助新手和非專業的 C++ 用戶去規避那些對高級庫實現提供支持的部分。

我建議使用 C++ 核心準則作為實現上述目標的一個輔助。

此外，我的「C++ 教程」也可以幫助人們在使用現代 C++ 時走上正確的方向，而不會迷失在自上世紀九十年代以來的複雜性中，或困惑於只有專家級用戶才能理解的東西中。這本即將出版的第二版的「C++ 教程」涵蓋了 C++17 和部分 C++20 的內容。

我和其他人給沒有編程經驗的大一新生教過 C++，只要你不去深入編程語言的每個晦澀難懂的角落，把注意力集中到 C++ 中最主流的部分，就可以在三個月內學會 C++。

「讓簡單的東西保持簡單」是我長期追求的目標。比如 C++11 的 range-for 循環：

for (int& x : v) ++x; // increment each element of the container v

v 的位置可以是任何容器。在 C 和 C 風格的 C++ 中，它可能看起來是這樣：

for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v

一些人抱怨說添加了 range-for 循環讓 C++ 變得更複雜了，很顯然，他們是正確的，因為它添加了一個新特性。但它卻讓 C++ 用起來更簡單，而且同時它還消除了使用傳統 for 循環時會出現的一些常見錯誤。

另一個例子是 C++11 的 標準線程庫 standard thread library 。它比起使用 POSIX 或直接使用 Windows 的 C API 來說更簡單，並且更不易出錯。

*Register：*您如何看待 C++ 現在的狀況？

Stroustrup：C++11 中作出了許多重大改進，並且我們在 C++14 上全面完成了改進工作。C++17 添加了相當多的新特性，但是沒有提供對新技術的很多支持。C++20 目前看上去可能會成為一個重大改進版。編譯器的狀況非常好，標準庫實現得也很優秀，非常接近最新的標準。C++17 現在已經可以使用，對於工具的支持正在逐步推進。已經有了許多第三方的庫和好些新工具。然而，不幸的是，這些東西不太好找到。

我在《想想瓦薩號！》一文中所表達的擔憂與標準化過程有關，對新東西的過度熱情與完美主義的組合推遲了重大改進。「追求完美往往事與願違」。在六月份拉普斯威爾的會議上有 160 人參與；在這樣一個數量龐大且多樣化的人群中很難取得一致意見。專家們也本來就有隻為自己設計語言的傾向，這讓他們不會時常在設計時考慮整個社區的需求。

*Register：*C++ 是否有一個理想的狀態，或者與之相反，您只是為了程序員們的期望而努力，隨時適應並且努力滿足程序員們的需要？

Stroustrup：二者都有。我很樂意看到 C++ 支持徹底保證 類型安全 type-safe 和 資源安全 resource-safe 的編程方式。這不應該通過限制適用性或增加性能損耗來實現，而是應該通過改進的表達能力和更好的性能來實現。通過讓程序員使用更好的（和更易用的）語言工具可以達到這個目標，我們可以做到的。

終極目標不會馬上實現，也不會單靠語言設計來實現。為了實現這一目標，我們需要改進語言特性、提供更好的庫和靜態分析，並且設立提升編程效率的規則。C++ 核心準則是我為了提升 C++ 代碼質量而實行的廣泛而長期的計劃的一部分。

*Register：*目前 C++ 是否面臨著可以預見的風險？如果有，它是以什麼形式出現的？（如，迭代過於緩慢，新興低級語言，等等……據您的觀點來看，似乎是提出的提議過多。）

Stroustrup：就是這樣。今年我們已經收到了 400 篇文章。當然了，它們並不都是新提議。許多提議都與規範語言和標準庫這一必需而乏味的工作相關，但是量大到難以管理。你可以在 WG21 網站上找到所有這些文章。

我寫了《想想瓦薩號！》這封信作為一個呼籲，因為這種為了解決即刻需求（或者趕時髦）而不斷增添語言特性，卻對鞏固語言基礎（比如，改善 靜態類型系統 static type system ）不管不問的傾向讓我感到震驚。增加的任何新東西，無論它多小都會產生成本，比如實現、學習、工具升級。重大的特性改變能夠改變我們對編程的想法，而它們才是我們必須關注的東西。

委員會已經設立了一個「指導小組」，這個小組由在語言、標準庫、實現、以及工程實踐領域中擁有不錯履歷的人組成。我是其中的成員之一。我們負責為重點領域寫一些關於發展方向、設計理念和建議重點發展領域的東西。

對於 C++20，我們建議去關註：

• 概念
• 模塊（適度地模塊化並帶來編譯時的顯著改進）
• Ranges（包括一些無限序列的擴展）
• 標準庫中的網路概念

在拉普斯威爾會議之後，這些都有了實現的機會，雖然模塊和網路化都不是會議的重點討論對象。我是一個樂觀主義者，並且委員會的成員們都非常努力。

我並不擔心其它語言或新語言會取代它。我喜歡編程語言。如果一門新的語言提供了獨一無二的、非常有用的東西，那它就是我們的榜樣，我們可以向它學習。當然，每門語言本身都有一些問題。C++ 的許多問題都與它廣泛的應用領域、大量的使用人群和過度的熱情有關。大多數語言的社區都會有這樣的問題。

*Register：*關於 C++ 您是否重新考慮過任何架構方面的決策？

Stroustrup：當我著手規劃新版本時，我經常反思原來的決策和設計。關於這些，可以看我的《編程的歷史》論文第 1、2 部分。

並沒有讓我覺得很後悔的重大決策。如果我必須重新做一次，我覺得和以前做的不會有太大的不同。

與以前一樣，能夠直接處理硬體加上零開銷的抽象是設計的指導思想。使用 構造函數 constructor 和 析構函數 destructor 去處理資源是關鍵（ 資源獲取即初始化 Resource Acquisition Is Initialization ，RAII）； 標準模板庫 Standard Template Library （STL） 就是解釋 C++ 庫能夠做什麼的一個很好的例子。

*Register：*在 2011 年被採納的每三年發布一個新版本的節奏是否仍然有效？我之所以這樣問是因為 Java 已經決定更快地迭代。

Stroustrup：我認為 C++20 將會按時發布（就像 C++14 和 C++17 那樣），並且主流的編譯器也會立即採用它。我也希望 C++20 基於 C++17 能有重大的改進。

對於其它語言如何管理它們的版本，我並不十分關心。C++ 是由一個遵循 ISO 規則的委員會來管理的，而不是由某個大公司或某種「 終生的仁慈獨裁者 Beneficial Dictator Of Life （BDOL）」來管理。這一點不會改變。C++ 每三年發布一次的周期在 ISO 標準中是一個引人注目的創舉。通常而言，周期應該是 5 或 10 年。

*Register：*在您的信中您寫道：

我們需要一個能夠被「普通程序員」使用的，條理還算清楚的編程語言。他們主要關心的是，能否按時高質量地交付他們的應用程序。

改進語言能夠解決這個問題嗎？或者，我們還需要更容易獲得的工具和教育支持？

Stroustrup：我儘力宣傳我關於 C++ 的實質和使用方式的理念，並且我鼓勵其他人也和我採取相同的行動。

特別是，我鼓勵講師和作者們向 C++ 程序員們提出有用的建議，而不是去示範複雜的示例和技術來展示他們自己有多高明。我在 2017 年的 CppCon 大會上的演講主題就是「學習和傳授 C++」，並且也指出，我們需要更好的工具。

我在演講中提到了構建技術支持和包管理器，這些歷來都是 C++ 的弱項。標準化委員會現在有一個工具研究小組，或許不久的將來也會組建一個教育研究小組。

C++ 的社區以前是十分無組織性的，但是在過去的五年里，為了滿足社區對新聞和技術支持的需要，出現了很多集會和博客。CppCon、isocpp.org、以及 Meeting++ 就是一些例子。

在一個龐大的委員會中做語言標準設計是很困難的。但是，對於所有的大型項目來說，委員會又是必不可少的。我很憂慮，但是關注它們並且面對問題是成功的必要條件。

*Register：*您如何看待 C++ 社區的流程？在溝通和決策方面你希望看到哪些變化？

Stroustrup：C++ 並沒有企業管理一般的「社區流程」；它所遵循的是 ISO 標準流程。我們不能對 ISO 的條例做大的改變。理想的情況是，我們設立一個小型的、全職的「秘書處」來做最終決策和方向管理，但這種理想情況是不會出現的。相反，我們有成百上千的人在線討論，大約有 160 人在技術問題上進行投票，大約有 70 組織和 11 個國家的人在最終提議上正式投票。這樣很混亂，但是有些時候它的確能發揮作用。

*Register：*在最後，您認為那些即將推出的 C++ 特性中，對 C++ 用戶最有幫助的是哪些？

Stroustrup：

• 那些能讓編程顯著變簡單的概念。
• 並行演算法 Parallel algorithms —— 如果要使用現代硬體的並發特性的話，這方法再簡單不過了。
• 協程 Coroutines ，如果委員會能夠確定在 C++20 上推出。
• 改進了組織源代碼方式的，並且大幅改善了編譯時間的模塊。我希望能有這樣的模塊，但是還沒辦法確定我們能不能在 C++20 上推出。
• 一個標準的網路庫，但是還沒辦法確定我們能否在 C++20 上推出。

此外：

• Contracts（運行時檢查的先決條件、後置條件、和斷言）可能對許多人都非常重要。
• date 和 time-zone 支持庫可能對許多人（行業）非常重要。

*Register：*您還有想對讀者們說的話嗎？

Stroustrup：如果 C++ 標準化委員會能夠專註於重大問題，去解決重大問題，那麼 C++20 將會非常優秀。但是在 C++20 推出之前，我們還有 C++17；無論如何，它仍然遠超許多人對 C++ 的舊印象。®

via: https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/

作者：Thomas Claburn 選題：lujun9972 譯者：qhwdw 校對：thecyanbird、Northurland、pityonline

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive