白喬原創：備受爭議的 Visual C++ 深度剖析

前言

Visual C++ 為讓程式設計師在 Windows 上自由使用 C++ 可謂「煞費苦心」，卻因歷史包袱與架構選擇長期飽受爭議。本文針對五大核心爭議點逐一剖析，還原技術脈絡。

爭議一：對標準 C++ 的支援度

歷史背景

• C++ 唯一國際標準：C++98 (ISO/IEC 14882:1998)
• VC++ 6.0 (1998 年釋出) 當時標準剛定案，支援度約 70%

客觀評價

要求 VC6 完整支援 C++98 猶如「要求山頂洞人狩獵必帶許可證」。後續版本（VC7.1 以降）支援度已超 98%，學習標準 C++ 請拋棄 VC6。

補充：2003 年 ISO 釋出 C++03（勘誤版），語法無變化，純修正錯誤。

爭議二：安裝體積過大

• VC6 ≈ 1 CD
• VC++ 2008 ≈ 2 GB

反駁：體積增長換取的是——

• 更豐富的類庫（STL、ATL、MFC 增強）
• 優異的 IDE 體驗（IntelliSense、重構、偵錯）
• 與 Office、SQL Server、Azure 等生態深度整合

儲存成本極低的今天，體積不應成為否決理由。

爭議三：MFC 的「依賴症」與封閉性

核心矛盾

MFC 將 Windows 物件高度封裝，導致：

• 程式設計師離開 MFC 就不會寫原生 Win32 代碼
• 不了解訊息映射、視窗類別註冊等底層機制
• 與開放技術（Qt、wxWidgets、Web 技術）互操作困難

微軟的應對：ATL

將輕量、通用的類別（CString、智慧指標、集合）下沉到 ATL，不再強制依賴 MFC 環境。現代 VC++ 專案可僅鏈結 ATL 即使用核心工具類。

爭議四：語言擴展與「旁門左道」

Java 可輕鬆實現執行時類型識別（RTTI）與反射：

Class clazz = obj.getClass();
Object instance = clazz.newInstance();

C++ 原生不支援，VC++ 引入 CObject、CRuntimeClass、巨集 DECLARE_DYNCREATE 等機制模擬反射。這套體系：

• 深度綁定 MFC 架構
• 依賴巨集與預處理器「黑魔法」
• 程式碼充滿 CObject 根類別，難以移植

爭議五：C++/CLI 與托管代碼

語法形式

String^ s = gcnew String("Hello");  // 托管參考型別
List^ list = gcnew List();

技術定位

• CLI (Common Language Infrastructure)：動態元件模型、虛擬執行系統（VES）
• C++/CLI：靜態 C++ 物件模型 → 動態 CLI 模型的綁定（斜線 / 象徵橋接）
• ECMA-372 標準化，VC++ 2005+ 完整支援

優勢

• 無縫互操作：同模組混用 Native / Managed 代碼
• GC 自動記憶體管理，消除緩衝區溢位與記憶體洩漏
• 類型安全、程式碼存取安全性（CAS）
• 直接使用 .NET BCL（網路、XML、加密、WCF、WPF…）

遷移策略

舊 C++ 代碼可漸進式遷移：核心邏輯保留 Native，邊界層用 C++/CLI 包裝暴露給 .NET 應用層。

總結

VC++ 的爭議本質上是「專有生態 vs 開放標準」的張力。理解其歷史脈絡、架構取捨，才能在技術選型時做出理性判斷——無論是堅持 Native C++、擁抱 C++/CLI、轉向 Qt/標準庫，還是跨平台部署。

本文出自 “白喬博客” 博客，請務必保留此出處 https://bluejoe.blog.51cto.com/807902/192763