COM 的跨平台替代品答案

【问题标题】：Cross-platform alternative to COMCOM 的跨平台替代品
【发布时间】：2010-10-31 22:37:51
【问题描述】：

我一直迷恋于基于组件的编程（无论是使用 COM、另一个系统，还是仅使用纯 C++ 中的范例）。如果一个人通常习惯于“传统”OOP 模型，它需要一点时间来适应，但它绝对值得。它使我的代码更易于维护和扩展。

我目前正在做的项目是使用范式，但没有设置系统。但是，我真的很想找到某种可以满足以下要求的系统。从我现在拥有的系统切换到新系统需要一些时间，但我会在以后节省很多时间。

要求：

跨平台
快
适用于 C++
支持跨进程编组

让我详细说明这些要求：

跨平台

基本上，我需要它在 Windows 和 Mac 上工作。 Linux 会很好，但绝不是必不可少的。此外，它确实需要满足所有平台的其他要求。有一个适用于 Mac 的 COM，非常理想，但它不支持要求 4。此外，它必须同时支持 GCC 和 MSVC。

快速

这是 CORBA 不幸失败的地方，尽管它满足了其他三个要求。进程内方法调用需要尽可能快（理想情况下，如 COM），因为某些例程也可能从音频中断中调用。

适用于 C++

...我想这个很明显。我不介意不使用 C++ 类来实现组件，尽管这肯定会有所帮助，而且替代方案必须仍然易于使用，特别是因为最终我打算发布一个用于 3rd 方扩展的 API。

支持跨进程编组

我的意思是至少能够序列化调用。如果这是通过从 IDL 生成的代码完成的，那对我来说完全没问题，而且我也不介意实现跨进程通信本身。

COM 会很好，但它不能完全满足要求 1。 CORBA 也会很棒，但它不满足要求 2（即使有最快的 ORB）。 XPCOM 可能不满足要求 2，并且不适用于 MSVC，因此不满足要求 1。

还有什么想法吗？我的下一步是使用 protobufs 或类似的东西来推出自己的产品，但我当然想避免这种情况。

更新

详细说明 - 这种情况下的音频中断可以低至 2-3 毫秒。那个时间对我来说甚至都不完整，因为其他组件需要在那个时间处理，而我的软件本身正在包装另一个需要在那个时间处理的软件。这就是为什么进程内和跨进程编组都需要非常快的原因。

【问题讨论】：

XPCOM 应该与 MSVC、AFAIK 一起使用。另外，如果没有，您不能只使用 MinGW 吗？
我可以使用 MinGW，但一方面，我的整个工具链都与 MSVC 集成在一起，虽然我也可以将 MinGW 集成到其中，但我无法使用 MSVC 中出色的调试器。
我认为如果你建造这个你会赚很多钱。进程中，进程外，pc，mac，linux，速度极快。大量的资金。 :)

标签： c++ c com cross-platform corba

【解决方案1】：

为了获得最大的广度，我只使用网络服务。面向服务的方法非常接近于面向组件的方法，因为只公开了服务契约（接口），而客户不需要知道服务内部工作的细节。

【讨论】：

他的性能要求可能排除了作为一种选择的可能性（尽管我同意，任何类型的基于 HTTP 的服务都是一个好的开始）。
确实，虽然原则上听起来不错，但不幸的是，要求在音频中断中运行它并不能实现。
没有看到中断要求。很惊讶听到有一个 COM 实现可以处理这个问题。
In-Proc COM 调用只是虚函数调用，非常快。跨进程的 COM 调用被序列化为二进制流并使用窗口消息发送，这些消息被优化到地狱（因为 Win32 基本上是围绕窗口消息转的）。
@arke：谢谢，我知道这些事情，并且很惊讶有一个 COM 的实现可以在内核模式下通过硬件中断轻松完成这些事情。我确信可以进行 Windows 内核调用，但不知道我会称它们为“简单”。

【解决方案2】：

ZeroC http://www.zeroc.com/ 的 ICE 是另一种选择。

对于那些 CORBA 的老前辈来说，Michi Henning 是当时的大师之一。他现在在 ZeroC 工作。它是一个开源的、跨平台的，包括您所有的目标（包括 Linux）、系统。

C++ 只是其中一种语言，ICE 的 C++ 绑定明显优于 CORBA C++ 绑定。

【讨论】：

【解决方案3】：

CORBA 肯定是一个答案 - 您应该在根据速度关闭它之前对其进行测试。

一个明确的替代方案是 XPCOM http://en.wikipedia.org/wiki/XPCOM - 缺少 MSVC 并不意味着不跨平台。

祝你好运

【讨论】：

你能推荐一个 ORB 实现吗？我试图找到一个网页，根据速度比较不同的 ORB，看看是否有一个足够快的，但我没有运气。
如果可以避免的话，你真的不想使用 CORBA——相信我。
TAO，“The ACE Orb”cs.wustl.edu/~schmidt/TAO.html 是一个非常受人尊敬的实现。
如果你想要进程内的速度，我认为 corba 是一个非首发。

【解决方案4】：

Qt 不应该是替代品吗？

http://qt.io

恕我直言。

【讨论】：

【解决方案5】：

为什么你认为 CORBA 不够快？你最近测量过东西吗？

CORBA 的现代实现可以在不到 150 微秒内进行远程调用。远低于您的 2 毫秒预算。 CORBA 的现代实现可以优化对基本上两个虚函数调用的进程内调用，尽管这通常需要应用程序放弃一些功能（例如拦截器）。即使在最坏的情况下，本地调用的全功能也是几个查找 +一些虚拟电话，我手边没有号码，但我确定它低于 50 微秒。

查看以下一些性能数据：

http://www.dre.vanderbilt.edu/Stats/performance.shtml

【讨论】：

【解决方案6】：

您说 CORBA 会很棒。我只能假设您从未使用过它。它是编程噩梦，不提供它声称的可移植性。如果现有应用程序已经实现了它，我只会使用它。但是，我不会因为性能原因而放弃它——我使用过的任何 CORBA 实现都没有遇到任何性能问题。

【讨论】：

【解决方案7】：

看看D-Bus（是的，对于windows too），它是各种组件框架（CORBA、Gnome Bonobo、KDE 的 DCOM）的现代精神继承者。

如果跨进程编组被证明是一个性能问题，请将繁重的工作转移到共享内存（boost.interprocess 将有助于保持跨平台）。

【讨论】：

【解决方案8】：

看看AF Architecture：

“Af-Arch 是一套完整的库和工具，允许开发分布式系统，专门用于解决商业应用程序的问题。”

我知道它适用于 linux 和 windows。我也知道它有一个非常快速的 C API 和 C# 绑定。

【讨论】：

一开始它看起来很吸引人，但这让我有点反感：“Af-Arch 编程模型包含基于 BEEP 核心之上的 XML 格式消息交换的 TCP 客户端-服务器系统协议。”。我担心这不会满足我的速度要求。 ://

【解决方案9】：

我认为你应该看看VortexLibrary。

它是一个完整的 BEEP 实现，为开发任何对等应用协议提供了良好的基础。它已经集成了身份验证（使用 SASL）和安全连接（使用 TLS），这两个选项都是可选的。

Vortex 还包括一个带有 IDL 编译器的 XML-RPC 配置文件的实现，它应该为您提供足够的编组基础......最好的是，您以后可以在顶部提供更具体的协议同一个会话，做二进制传输，不受 XML-RPC 的限制。

它是用 C 编程的，但也适用于 c++。目前它正在运行，回归测试确保它在 Linux、Windows 和 MAC 下的功能。

干杯！

【讨论】：