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

Do COM or CORBA bring forward compatibility of compiler or of standard library?

本题紧接上一题:

我想知道用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。

非常感谢!

是的,除其他原因外,创建 COM 是为了克服源代码(和 .obj、静态库等)重用问题,无论该源是 C/C++ 还是其他任何东西。

COM的本质(v-tablelayout + IUnknown,忘记注册,OLE,Automation,marshaling,和其他额外的东西)很简单(事实上,很难让它更简单).由于它仅依赖于二进制合约,因此您可以使用任何语言(和任何平台,但实际上只有 Windows 使用它)编写 COM 客户端 and/or 服务器代码。因此,您可以让一个用 python 编写的 32 位 COM 客户端与一个用 C++ 编写的 64 位 COM 服务器通信(好吧,这个例子实际上需要一些跨进程编组,所以它不是纯粹的轻量级 COM) .

COM 离消亡或消失还很遥远(因为它非常简单)。 "ActiveX" 是一个营销/技术组合名称,但它基本上是 COM,并且在 Windows 中被 Windows 和第 3 方大量使用。

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

我知道 CORBA 曾经是 COM 的强大竞争对手(特别是因为它在多个平台上可用,包括 Windows),但它似乎正在严重衰落,同样有利于更简单的技术(网络等)。