小編精選 - 技術文章翻譯 · 09月11日

捍衛 C++

C++的聲譽

C++ 經常因其複雜性、高學習曲線而飽受批評，最重要的是，它不僅會讓開發者搬起石頭砸自己的腳，甚至可能在這個過程中毀掉自己的整條腿。但這些批評經得起推敲嗎？

好吧，在這篇文章中，我旨在解決一些對 C++ 最常見的批評，並對其優點和缺點提供一個平衡的觀點。

C++很“複雜”

C++ 確實是一門複雜的語言，擁有豐富的特性與功能。對於任何你想用 C++ 實現的功能，大約有十幾種不同的方法來實現，每種方法都有其自身的利弊和影響。那麼，身為開發者，你如何知道哪種方法最適合你的特定用例呢？你當然必須對這門語言有深入的理解才能做出這些決定，對吧？

並非如此……我的意思是，別誤會我的意思，這確實有幫助，但並非硬性要求。過早優化是萬惡之源，而在 C++ 中，你可以寫出完美的程式碼，而無需擔心語言中更複雜的特性。你可以在 C++ 中編寫簡單、易讀且易於維護的程式碼，而無需使用模板、運算子重載或該語言的任何其他更高級的特性。

有一種觀點認為，用任何程式語言做任何事，都需要盡可能使用最高效、最正確的方法。 Python 以其 Python 式的做事方式做到了這一點，Java 如此，C# 如此，Go 也是如此。哎呀，就連像在瀏覽器上繪製 HTML 這樣簡單的事情，也需要每隔幾年就重新發明一次，並且爭論不休。然而，事實是，在大多數情況下，做某事並沒有唯一正確的方法。所謂的「最佳方法」通常只是個人或團隊偏好的問題。那種認為只要用「最佳」和正確的方式編寫程式碼，就永遠不需要擔心維護的想法，簡直是錯誤的。

不要太在意使用「最佳」方法；更要考慮如何編寫易於閱讀和理解的程式碼。如果你能做到這一點，就沒問題了。

C++已經“過時”

C++ 的歷史非常悠久。事實上，它誕生於 1985 年。確切地說，這比 Windows 的第一個版本發布早了 4 年，比 Linux 的第一個版本發布早了 6 年，或者更確切地說，比最後一台 8 位元電腦的發布早了 6 年。所以，無論以何種標準衡量，C++ 都算是相當古老了。但這就意味著它已經過時了嗎？

當然，C++ 並非自 1985 年發布以來就一直保持不變。 40 多年來，C++ 一直在積極開發和改進，並不斷加入新的功能和功能。 C++ 標準的最新版本 C++ 20 於 2020 年發布，為該語言引入了許多新功能和改進。 C++ 23 也即將問世，預計將為語言帶來更多改進。

在這些改進中，最關鍵的是模組、概念、範圍和協程。這些特性為 C++ 帶來了現代程式設計範式，使其比以往任何時候都更加強大、更具表現力。

但是戴夫，我們所說的過時是指其他語言已經超越了 C++ 並提供了更好的開發人員體驗。

我想，這或許只是個人喜好問題，C++ 仍然是最廣泛使用的程式語言之一，擁有龐大的函式庫和工俱生態系統。它被廣泛應用於遊戲開發、高效能運算和嵌入式系統等各種領域。世界上許多最受歡迎、使用最廣泛的軟體應用程式都是用 C++ 編寫的。

我並不認為 C++ 已經過時了；你必須對過時的定義進行很大程度的改變才能得出這樣的結論。

C++ 是“不安全的”

啊，終於，我們談到最重要的問題了，是的，我會將其與 Rust 進行比較，因為它是一種「記憶體安全」語言，很多人聲稱它將或應該取代 C++。

事實上，我們現在就來討論一下主要觀點。

將 C++ 程式碼庫重寫為 Rust 總是能比以前產生更記憶體安全的結果。

無數公司都曾提到，他們只是用 Rust 重寫 C++ 程式碼庫，就提高了安全性或減少了報告的錯誤或記憶體洩漏的數量。

那麼，這是因為 Rust 嗎？我認為，在某種程度上，是的。然而，我認為最大的因素是，任何對現有程式碼庫的重寫都會產生比原始程式碼庫更好的結果。

重寫程式碼庫時，您有機會重新思考和設計架構、修復錯誤並提升程式碼的整體品質。您可以利用從先前的實現中汲取的所有經驗教訓、所有已發現和修復的問題以及您已知的問題。所有在現有程式碼庫中難以修復的問題，您都可以在新的程式碼庫中輕鬆解決。

想像一下，你建了一個棚屋，它有點搖搖晃晃，而且你剛開始建造的時候不太懂木工技術，所以它還有一些其他問題，比如結構完整性和屋頂漏水。幾年後，你又建了一個新棚屋，這次你徹底認清了第一次建棚時犯的所有錯誤，所以你把它建得更好、更堅固、更防風雨。在這個過程中，你決定更換之前使用的材料，例如，你選擇橡木而不是楓木。這麼說，新棚屋更好只是因為你用橡木代替了楓木，對嗎？或者這只是整體改進的一小部分？

當我看到這些公司聲稱用 Rust 重寫他們的 C++ 程式碼庫讓他們的記憶體更安全時，我就是這麼想的。這並不是 Rust 的功勞，而是因為他們花時間重新思考和設計了他們的程式碼庫，並吸取了之前實現過程中的所有經驗教訓。

但這並不能否認C++不安全的事實。

是的，如果你不知道自己在做什麼，C++ 可能不安全。但問題是：如果你不知道自己在做什麼，所有程式語言都是不安全的。你可以在 Rust 中編寫不安全的程式碼，你可以在 Python 中編寫不安全的程式碼，你可以在 JavaScript 中編寫不安全的程式碼。

記憶體安全只是程式語言安全性的一個面向；你仍然可以用記憶體安全的程式語言編寫不安全的程式碼。僅僅使用 Rust 並不能神奇地讓你的應用程式變得安全；它只會讓記憶體洩漏或安全問題的發生變得更加困難。

在這種情況下，「不安全」一詞有點過於模糊，我認為它被用作一個包羅萬象的術語，在我看來，這充滿了行銷語言。

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++ 擁有龐大的生態系統，歷經 40 多年的發展，擁有許多不同的函式庫和工具。這使得我們很難確定應該使用哪些函式庫和工具來完成特定任務。但這並非 C++ 獨有，每種程式語言都存在這個問題。

再次強調，簡單的經驗法則是盡可能使用標準函式庫；它維護良好，並且擁有許多實用的功能。對於網路或 GUI 開發等其他任務，有許多廣泛使用且維護良好的知名程式庫。您可以做一些研究，找出最適合您特定用例的程式庫。

盡量避免使用 Boost。 Boost是一個龐大的函式庫集合，在 C++ 社群中被廣泛使用。然而，Boost 中的許多程式庫已經過時，不再維護。它們也往往相當複雜，難以使用。如果可以避免使用 Boost，請盡量避免。

除非您正在編寫一個需要 Boost 提供的特定功能的大型複雜應用程式，否則最好使用其他更現代、更易於使用的程式庫。除非確實需要，否則不要在您的應用程式中增加 Boost 的效能開銷和二進位檔案大小。

C++ 對初學者來說不是一個好的選擇

程式設計對初學者來說不是一個好選擇，木工對初學者來說不是一個好選擇，汽車修理對初學者來說也不是一個好選擇。程式設計很難；學習它需要時間和精力，就像所有事情一樣。沒有一種通用的語言真正適合初學者；每件事都有其優點和缺點。

事實上，如果你想進入系統程式設計或遊戲開發之類的領域，那麼從 Python 或 JavaScript 開始學其實沒什麼用。你最終還是需要學習 C 或 C++。

如果您的目標是成為 Web 開發人員或資料科學家，那麼請從 Python 或 JavaScript 開始。

如果你只是想在程式設計行業找一份工作，我不知道，學習 Java 或 C#，這兩種都是很棒的語言，雖然受到了很多不應有的憎恨，但卻提供了大量的工作機會。

事情是這樣的：如果你剛開始學習編程，那麼無論你選擇哪種語言，都會很難。實際上，我認為從 C 或 C++ 開始比從那些晦澀難懂的程式語言開始要好得多。我進一步指出，從 Python 或 JavaScript 開始，從長遠來看是對自己不利的，因為你要犧牲在對某個主題的理解尚且新鮮且易於理解時學習的痛苦，來換取在對現有程式設計理解有更深入的了解後再學習的痛苦。

但是，這只是我的看法。

C++ 與 Rust：朋友還是對手？

近年來，Rust 贏得了許多青睞，這並非偶然。它非常重視記憶體安全，其藉用檢查器強化了 C++ 通常留給程式設計師的規則。即便如此，Rust 仍在建立其生態系統，學習曲線可能同樣陡峭——只是方式不同。 C++ 可能無法避免你搬起石頭砸自己的腳，但它提供了數十年久經考驗的工具、編譯器和函式庫，為從 Chrome 到虛幻引擎的所有應用提供支援。實際上，許多團隊將 Rust 和 C++ 結合使用，而不是將它們視為敵人。 Rust 在以安全為首要任務的新專案中大放異彩，而 C++ 則繼續在遺留系統和效能關鍵領域佔據主導地位。

2025 年還會使用 C++ 嗎？

簡短的回答：絕對是如此。儘管人們一直說 C++ 已經過時，但它仍然是世界上使用最廣泛的語言之一。 Chrome 和 Firefox 等主流瀏覽器仍然用它編寫。虛幻引擎等遊戲引擎也執行在它之上。汽車系統、金融交易平台，甚至人工智慧框架，在效能和控制方面都嚴重依賴 C++。新標準（C++20、C++23）不斷更新語言，確保它與新興的替代語言保持競爭力。如果你深入研究我們日常依賴的大多數大型系統，你幾乎總是能發現 C++ 在底層默默地運作。