C++ 論戰中的謬誤與迷思：參與技術討論前的認知疫苗

為何技術社群充滿謬誤？

資訊在口耳相傳中會被主觀意識修飾、扭曲——語言本身具有建構現實的力量，不同立場解讀同一句話可得截然相反的結論。加上「不願承認不知情」、「維護心理優勢/利益」、「人雲亦雲」等心理機制，謬誤 (Fallacies) 與迷思 (Myths) 便在長期爭論中固化。

C++ 社群的核心謬誤剖析

謬誤 #1：C++ 社群哲學過於「學院派」

真相：C++ 設計原則之一即「不要陷入對完美的固執追求」(Bjarne Stroustrup)。所謂「學院派」實指：
• 過度關注語言陰暗角落 (如 SFINAE、模板元編程技巧)
• 將語言特性本身當作目標，而非解決問題的工具
• 標準化提案多聚焦語言機制，而非實際開發痛點

成因：現代 C++ 庫開發 (Boost、STL) 確實需要深鑽語言細節 (如 enable_if, type_traits)，這種「庫設計者的必要條件」被錯誤推廣為「所有 C++ 程式設計師的充分條件」。

謬誤 #2：C++ 太難正確使用，不如用 C

許多批評者從未深度使用現代 C++ (C++11/14/17/20)，或非合格 C++ 開發者。實際上：

• RAII + 智慧型指標 + 算法庫，讓資源管理比 C 更安全、更簡潔。
• 編譯期型別檢查捕獲大量 C 執行期才會炸的錯誤。
• 關鍵在於「用對子集」：嵌入式用 -fno-exceptions -fno-rtti，應用層大方用標準庫。

謬誤 #3：多重繼承本質邪惡，Java 捨棄它是正確的

Eiffel 證明多重繼承可被優雅解決 (重命名、選擇、未定義)。C++ 採用域解析操作符 :: 消除歧義，雖顯醜陋但實用。Java 採用介面替代，本質是「單一實作繼承 + 多重型別繼承」，解決了菱形繼承的狀態衝突，但犧牲了 Mixin 模式的表達力。孰優孰劣取決於應用場景，無絕對真理。

建立理性討論框架

1. 區分「語言機制」與「設計模式」：不要拿語言細節缺陷攻擊設計模式價值，反之亦然。
2. 場景化論證：任何技術選型結論必須前置「在 XXX 場景下，受 YYY 約束」。
3. 承認認知邊界：敢於說「我不知道」，拒絕人雲亦雲。
4. 回歸工程本質：代碼能否正確、高效、可維護地解決問題，才是唯一試金石。