為什麼用C或C++表達Windows COM技術那麼複雜呢？是C或C++缺少什麼嗎~

01-15

又要 C++

又要 OO

又要可以動態鏈接

還要保證二進位兼容 // ← 這條相當難

這需求沒法做得好看

其實我試著造過類似的輪子。。然而只能練練手。

不過視野很重要，做這個你要解決的範圍多大，性能上能接受多大的妥協都是設計上需要考慮的。像COM這種意圖打通語言邊界，進程邊界乃至機器邊界的設計是非常難以面面俱到的。

一個典型的代價是，COM的規範為了適配不同的語言，對象類型的機制非常複雜。如果你用過typelib系列的API的話，就知道對象成員，方法，參數的信息表達是很不直觀的，為了考慮語言特性，會有很多兼容設計。嵌套類型想要解析出來也需要下一番功夫。

另外還有一個問題，COM需要統一註冊，而很多人喜歡用綠色軟體往往缺少這個過程導致功能異常。已經刪除的軟體由於程序員的疏忽也非常容易在註冊表裡留下垃圾。

原來玩dx時候碰過點，感覺挺好的，這不是c++多態性和虛函數最好的體現么。初學c++時一直不懂虛函數有什麼用，見到這個豁然開朗。

這不是C++缺什麼，而是跟COM的設計目標有關。COM要解決的問題大致有這些：

1，跨語言的互操作：C++、VB、JS等語言之間互相調

2，組件服務的可見性：需要一個倉庫（註冊表）登記提供服務的組件讓使用者可以找到

3，組件的線程安全：需不需要考慮線程安全？在調用者線程執行還是在組件的工作線程執行？誰加鎖？COM提供了三種選擇。

4，調用的許可權控制：調用者有沒有許可權使用組件提供的服務？

5，跨進程：RPC

6，跨機器（DCOM）

7，事務性支持（COM+）

無論用什麼編程語言，要實現這些設計目標，都不會很簡單。

一個類似的例子是Android的Binder框架。它要解決的問題跟COM很相似：

1，跨語言：C++、JAVA

2，服務的可見性：組件需要註冊到Service Manager

3，線程的安全性：組件自己解決，框架不管

4，調用的許可權控制：checkPermission。。。

5，跨進程：Binder Driver

如果把目標簡化一點，比如不考慮跨語言、跨進程、許可權檢查等目標，自己寫一個COM框架其實不複雜。

com其實就是利用c++的虛函數動態綁定技術，這種技術作為介面是有缺陷的，詳情看c++虛函數細節。

COM本來就是C/C++實現的，所以一些實現細節都暴露出來了，看起來就複雜。

別的那些語言，COM介面的底層也是C/C++實現的，所以沒有底層細節可以暴露給你。你看到的只有高層介面，看起來就簡單。

不過，C++你要是只用ATL之類的，其實也就差不多了。

請詳述一下「複雜」是指什麼樣的複雜？COM的設計思想是介面與實現分離，以及代碼的二進位重用，這些東西基於C/C++，但和語言也不是那麼緊密相關。請不要由此發散開就得出結論C/C++缺少了什麼。

COM本來就是基於C++設計的，你覺得複雜說明你還沒弄懂COM的機制。C/C++都是偏低層的語言，需要你去了解底層細節。如果你並不關心底層，就不要使用C/C++

更多的複雜還是來自於C++本身，大量近似但又不同的類型。想想光表示字元串有多少種方式和類型。