C++ 的設計哲學深受 Bjarne Stroustrup 早期經驗影響：他試圖在單一巨石模塊內管理複雜度，而非利用 UNIX 風格的「小工具協作」。這導致 C++ 在進程創建開銷低的 UNIX 上失去優勢，反而在進程開銷高的 Windows 上成為主流。本文從《The Art of UNIX Programming》視角重審 C++ 與作業系統的共演歷史。
核心論點：C++ 是「源代碼級內部分層」的替代品
「如果作業系統讓創建進程過於昂貴，就會鼓勵在巨石模塊內部使用 C++ 這類源代碼級內部分層，而不是 C 這樣的小模塊協作。」 —— 《The Art of UNIX Programming》3.1.3
歷史脈絡對比
| 維度 | UNIX 文化 | Windows/PC 文化 |
|---|
| 核心機制 | 進程 + IPC（管道、Socket、共享內存） | 單進程多線程、COM、DLL |
| 進程創建開銷 | 極低（fork/exec 優化） | 極高（進程重、線程輕） |
| 複雜度管理 | 拆分為多個協作小程式 | 單一大程式內部用 C++ 類別/模板分層 |
| 代表語言 | C、Shell、腳本語言 | C++、C#、Java |
Stroustrup 的局限性：僅著眼源代碼層
- 博士論文寫模擬器時，缺乏合適工具管理單一巨石程式的內部複雜度。
- 未考慮「將巨石拆分為協作進程」這一更高層級架構選項。
- C++ 由此誕生：在源代碼層面提供類別、繼承、模板、命名空間等組織手段。
Linux 核心證明：C 足以管理百萬行巨石
- Linux 核心為單一巨石架構，超過 2000 萬行代碼，純 C 編寫。
- 模組化設計（子系統、分層架構）無需 C++ 特性即可實現。
- 多線程檔案系統、鎖機制、RCU 等高並發設施皆在 C 層面優雅實現。
- 微核心派曾宣稱「巨石複雜度不可控，必須微核心」，Linux 以事實反駁。
現代啟示：若你的組件複雜度超過 Linux 核心，那是架構罪過
- 單一模塊超過核心複雜度 → 應拆分服務/進程，而非引入 C++ 管理內部複雜度。
- 微服務、容器、gRPC 等現代基礎設施，正是「UNIX 哲學在雲端的延伸」。
- C++ 仍有價值：高效能庫、遊戲引擎、嵌入式、編譯器等「極致效能單進程」場景。
結語：C++ 的興起是歷史錯位的產物
- 80 年代 UNIX 廠商內鬥導致 UNIX 文化衰退。
- PC 市場崛起，缺乏低開銷進程/IPC 機制。
- 開發者被迫在單進程內管理複雜度，C++ 填補了工具鏈真空。
- 今日雲原生時代，UNIX 哲學（進程隔離、協作、可觀測）強勢回歸，C++ 的「巨石內部分層」定位將持續收縮。
理解這段歷史，不是為了否定 C++，而是為了在架構選型時擁有更宏觀的視野：能用進程解決的，就別用類別解決。
