COM 或 CORBA 是不是带来了编译器或标准库的兼容性？

Posted 2023-02-16

【中文标题】COM 或 CORBA 是不是带来了编译器或标准库的兼容性？

【英文标题】：Do COM or CORBA bring forward compatibility of compiler or of standard library?COM 或 CORBA 是否带来了编译器或标准库的兼容性？

【发布时间】：2018-01-02 08:31:38

【问题描述】：

本题紧随上一题：

Easy way to guarantee binary compatibility for C++ library, C linkage?

我想知道用C链接制作C++ DLL或共享库的接口函数是否会带来编译器和标准库的兼容性。

extern "C" someAPI();

投票最多的答案是说我错了。答案建议将其开源。并且从未提及 COM 或 CORBA。将其开源并不总是可行的。

但最近我正在阅读有关 Windows COM 的书籍。而且我认为 COM 可能会带来我想要的兼容性。还有另一件事 CORBA。

所以我想知道COM和CORBA这些东西是否真的带来了编译器和标准库的兼容性？

我认为网络库 ACE 使用 CORBA。这只是我对 CORBA 的了解。 CORBA 现在不是很流行吗？ COM 呢？ ActiveX 可能正在消失，但 WDF(Windows Driver Foundation) 依赖于 COM。

非常感谢！

【问题讨论】：

我不熟悉 CORBA。 COM 通过（除其他外）严格限制允许的方法参数类型和返回值到 POD 类型的子集来确保二进制兼容性。特别是，在 COM 接口中不能提及标准库类（或就此而言，用户定义的类），这使得标准库兼容性问题变得毫无意义。

【参考方案1】：

是的，COM 的创建主要是为了克服源代码（以及 .obj、静态库等）的重用问题，无论该源是 C/C++ 还是其他任何东西。

COM 的本质（v-table 布局 + IUnknown，忘记注册、OLE、Automation、marshaling 和其他附加内容）非常简单（事实上，很难让它变得更简单）。由于它仅依赖于二进制合约，因此您可以使用任何语言（和任何平台，但实际上只有 Windows 使用它）编写 COM 客户端和/或服务器代码。因此，您可以让一个用 python 编写的 32 位 COM 客户端与一个用 C++ 编写的 64 位 COM 服务器通信（好吧，这个例子实际上需要一些跨进程封送处理，所以它不是纯粹的轻量级 COM）。

COM 远未消亡或消失（因为它再次非常简单）。 “ActiveX”是一个营销/技术组合名称，但它基本上是 COM，并且在 Windows、Windows 和第 3 方中大量使用。

物理网络上的 COM (DCOM) 确实正在消失（有利于其他技术，如 Web、套接字、HTTP、REST 或比 COM 更简单的一般技术），而今天仍在使用的基本上是进程内的和外进程 COM（外进程在某种程度上是同一台机器上的 DCOM）。

我知道 CORBA 曾经是一个强大的 COM 竞争对手（尤其是因为它可以在多个平台上使用，包括 Windows），但它似乎正在严重下降，也有利于同样更简单的技术（Web、等等）。