精通 C++ 的記憶體與架構：來自 Bjarne Stroustrup 的洞察
記憶體洩漏與架構不穩定是 C++ 開發中長久存在的幽靈。對許多人來說，這門語言被視為充滿手動 new 與 delete 調用的雷區，只要漏掉一個指標，就會導致災難性的洩漏。然而，C++ 的創作者 Bjarne Stroustrup 主張，解決方案並非更謹慎的手動追蹤，而是對語言抽象方式的根本性轉變。
在他技術性的 FAQ 中，Stroustrup 概述了一種「資源安全」的哲學，這種哲學從低階的記憶體機制轉向一種由類型來隱式管理資源的模型。這種方法不僅消除了洩漏，還優化了建置時間與執行時效能。
與記憶體洩漏的戰爭：隱式優於顯式
當被問及如何處理記憶體洩漏時，Stroustrup 的回答非常直白：寫出不會有任何洩漏的程式碼。
他認為，如果一個程式充斥著顯式的 new 與 delete 操作和指標算術，無論程式設計師的技術如何，洩漏都是不可避免的。程式碼的複雜度最終會超過人類追蹤每一次配置的處理能力。成功的關鍵在於將配置與釋放隱藏在可管理的類型之中。
標準容器的力量
Stroustrup 提倡大量使用 std::vector 和 std::string 等標準函式庫容器。這些工具會自動管理其元素的記憶體。當一個 vector 需要更多空間時，它會進行配置；當它超出作用域時，它會釋放。
"透過將我必須顯式追蹤的物件數量從數萬個減少到幾十個，我將使程式正確運作所需的智力成本從一項艱巨的任務轉變為可控、甚至簡單的任務。"
RAII 與資源句柄
對於無法由容器處理的資源，Stroustrup 指向了 RAII (Resource Acquisition Is Initialization)。其核心思想是將資源（記憶體、檔案句柄、鎖）的生命週期與局部物件的生命週期綁定在一起。物件的建構函式負責獲取資源，而解構函式則負責釋放它。
這種模式優於其他語言中的 finally 區塊，因為它更簡潔且不易出錯。如果拋出異常，堆疊會展開，並調用所有局部物件的解構函式，確保無論從哪個路徑退出，資源都會被釋放。
架構穩定性與建置效能
除了記憶體，Stroustrup 還探討了一個常見的抱怨：編譯時間緩慢。他將其歸因於設計不良——特別是「脆弱的基底類別問題」。
純介面與實作數據
許多開發者將共享的實作數據（protected 成員）放入基底類別中。這會造成一種依賴關係，即每當 protected 區段中的微小實作細節發生變化時，基底類別的所有使用者都必須重新編譯，即使公開介面保持不變。
Stroustrup 的解決方案是使用 純介面（僅包含純虛擬函式的抽象類別）。透過將數據從介面中移除並移至衍生類別中，使用者可以免受實作變更的影響，從而大幅降低建置時間。
C++ 設計原理：功能背後的「為什麼」
Stroustrup 提供了關於幾個具備爭議性的 C++ 設計選擇的關鍵背景資訊：
- 虛擬函式： 成員函式預設不是虛擬的，因為許多類別並非旨在作為基底類別。增加虛擬表 (vptr) 會增加開銷，並可能破壞與 C 或 Fortran 的佈局相容性。
- 虛擬建構函式： 這些並不存在，因為建立物件需要完整的類型資訊，而虛擬調用則是為了與部分資訊配合運作而設計的。
final關鍵字： 在 C++11 中引入，final允許開發者停止進一步的衍生，這對於邏輯安全性（防止切片）和潛在的優化都有幫助。- 指標與引用： 引用主要是為了支援算符重載，並提供比指標更簡潔的語法，儘管指標仍保留以維持與 C 的相容性，以及在「null」為有效狀態的情況下使用。
- 宏 (Macro) 的威脅： 宏在編譯器看到程式碼之前就在處理字元流，忽略了作用域與類型規則。這會導致微妙的錯誤，例如在像
#define square(x) (x*x)這樣的宏中對參數進行雙重求值，這會導致square(i++)使i增加兩次。
常見陷阱與現代替代方案
陣列的危險
Stroustrup 警告強烈反對使用原始陣列，並指出了兩個根本缺陷：它們不知道自己的大小，且極易退化為指標。這會導致緩衝區溢位，並在繼承過程中產生災難性的行為（例如將 Derived[] 當作 Base[] 處理時會導致錯誤的指標算術）。
替代方案： 使用 std::vector。它更安全、更易讀，且在大多數情況下效能與原始陣列相當。
宏 (Macro) 的威脅
宏被不建議使用，因為它們在編譯器看到程式碼之前就在處理字元流，忽略了作用域與類型規則。這會導致微妙的錯誤，例如在像 #define square(x) (x*x) 這樣的宏中對參數進行雙重求值，這會於 square(i++) 時使 i 增加兩次。
替代方案： 使用 inline 函式、模板與命名空間。
社群觀點
雖然 Stroustrup 的指南具有權威性，但開發者社群經常指出這些理想與現狀之間的差距。一些 Hacker News 的評論者指出，雖然 RAII 是強大的，但像 std::auto_ptr（現在已棄用，改由 std::unique_ptr 取代）與 std::sort 這類舊工具的組合在早期 C++ 版本中可能很脆弱。
其他人則指出，即使在垃圾回收 (GC) 語言中，記憶體洩漏仍然以「遺忘」的形式存在。