Bjarne Stroustrup 專訪：C++ 演進哲學、語言趨勢、並發未來與 C++0x 展望

語言設計哲學

為何語言引發「粉絲戰」？

語言成為思維延伸，單一語言限制溝通。專家需掌握多語言及工具鏈，理解基本原理超越語法。經濟因素：技能不可遷移造成壁壘。

IDE 角色定位

IDE 應理解語言、響應迅速，但不應成為語言一部分。代碼可移植性優先：源碼應自包含表達系統邏輯，不依賴 IDE 生成/轉換代碼。

可讀性與復雜性

語法簡單優於複雜，但抱怨多針對領域固有復雜性。通用語言必須適應多樣應用，領域專用語言（DSL）雖簡潔但引入多語言交互復雜度。

多重分派

單分派無法優雅表達雙參數運算（矩陣乘法、圖形相交）。運行時多重分派（Dylan/CLOS）優於訪問者模式；編譯時多重分派（C++ 模板技巧）更高效。Stroustrup 團隊已發布向 C++ 添加多重分派的論文，生成代碼更簡短、快速、省內存。

協變/逆變

C++ 現狀足夠。隱式運行時檢查 vector<Apple> → vector<Fruit> 不安全（除非不可變）。

消息傳遞 vs 方法調用

偏好顯式消息傳遞（避免共享鎖問題），但需語言/工具支持完善。期待標準庫納入相關設施。

語言發展趨勢

動態語言會成主流嗎？

不會。靜態/動態非二元對立：動態語言有靜態部分，靜態語言有動態特性。選擇取決於應用需求、領域、團隊技能。

移除 void*/variant/object？

理論可行但需完整分類系統。C++ Concepts（約束）有助表達需求，但仍需「真正未知類型」的表達能力。

匈牙利命名法

堅決反對。源碼應反映語義而非模擬類型系統。若覺得需要，說明語言與應用不匹配。

AOP 與 Wrap<T>

支持非入侵式組合（C++ 模板/STL 已驗證）。擔心超語言工具、非標準工具鏈。C++0x 嘗試在不犧牲靈活性/性能下解決。

C++ 歷史遺留問題

• 宏濫用 → 十年前環境惡化主因。
• 初始化語法過多混亂 → C++0x 統一初始化。
• 默認值錯誤：構造函數隱式轉換、名稱默認外部可見。
• 鏈接模型不可控，實現差異大。
• 意外收穫：析構函數 + 異常 = RAII，資源管理核心模式。

方法論與最佳實踐

• 核心流程：識別關鍵概念 → 設計庫 → 早期實驗/集成/測試 → 文檔作設計工具 → 從小程序迭代生長。
• 庫設計即架構設計，語言特性決定開發方法適用性。
• 經驗法則：關注關鍵概念接口、資源管理（RAII）、錯誤處理、類不變體。
• 「敏捷」概念模糊，C++ 當然支持任何合理流程。

展望未來

高級特性與新手友好

穩定性至關重要（舊代碼十年不斷）。C++0x 引入統一初始化、auto 類型推導、Concepts 約束，降低使用門檻。

元數據

個人極不喜歡大量元數據。

多核與並發

C++0x 提供：多線程內存模型、基礎原語（原子操作、鎖）、thread/mutex 標準庫。期望更高層模型：線程池、任務、消息隊列。自動計算分佈到多核仍在研究（STAPL、TBB）。

GPGPU 通用計算

關注但缺實戰經驗，需專用技能。

HPC 透明化

略微透明，但並發不可完全透明（錯誤處理、共享內存、延遲）。庫/框架層面推進，語言需提供底層保證（C++0x 已做）。

C++0x 進度

接近完成。計劃：6 月發布委員會草案供公眾評論，12-18 個月後國際標準發布。相關資料：HOPL 文章、WG21 文檔、主頁視頻。

閱讀清單

• 技術：Hennessy & Patterson 《計算機體系結構》、Knuth 《TAOCP》、C++ 標準化文檔。
• 非技術：O'Brian 《Aubrey-Maturin 系列》、Dawkins 科普、Rodger 《大洋制勝：英國海軍史》。

關於手機

不熱衷智能手機，偏好面對面或郵件溝通。當前手機功能多餘，語音質量不可靠，界面雖改進但非核心需求。