这个问题遵循以下的问题：
Easy way to guarantee binary compatibility for C++ library, C linkage?
我想知道是否使用C链接创建C ++ DLL或共享库的接口函数会带来编译器和标准库的兼容性。
extern＆＃34; C＆＃34; someAPI（）;
投票最多的答案是说我错了。答案建议将其开源。从未提及COM或CORBA。开源并不总是可行的。
但最近我正在阅读有关Windows COM的书籍。我认为COM可能会带来我想要的兼容性。 CORBA还有另一件事。
所以我想知道这些东西，COM和CORBA，是否真的带来了编译器和标准库的兼容性？
我认为网络库ACE使用CORBA。这只是我对CORBA的了解。 现在不是很受CORBA欢迎吗？ COM怎么样？ ActiveX可能正在消失，但WDF（Windows Driver Foundation）依赖于COM。
非常感谢！
答案 0 :(得分：3)
是的，除了其他原因之外，还创建了COM来克服源代码（和.obj，静态库等）重用问题，无论该源是C / C ++还是其他任何东西。
COM的本质（v-table布局+ IUnknown，忘记注册，OLE，自动化，编组和其他附加的东西）非常简单（事实上，很难让它变得更简单）。由于它只依赖于二进制契约，因此您可以使用任何语言（以及任何平台，但实际上只有Windows使用它）编写COM客户端和/或服务器代码。因此，你可以将一个32位的COM客户端编写成一个用C ++编写的64位COM服务器（例如，这个例子实际上需要一些跨进程封送，所以它不是纯粹的轻量级COM）。
COM远非死亡或消失（因为它再次非常简单）。 “ActiveX”是一个营销/技术组合名称，但它基本上是COM，并且在Windows，Windows和第三方中大量使用。物理网络（DCOM）上的COM确实正在消失（支持其他技术，如Web，套接字，HTTP，REST，或者比COM更简单的一般技术），而今天仍然使用的基本上处于进程中和进程外COM（进程在同一台机器上以某种方式DCOM）。
我知道CORBA曾经是一个强大的COM竞争对手（特别是因为它可以在多个平台上使用，包括Windows），但它似乎正在严重衰退，也支持同样更简单的技术（网络，等）。