COM的跨平台替代方案

ark*_*rke 9 c c++ com cross-platform corba

我一直迷恋于基于组件的编程(无论是COM,另一个系统,还是只使用普通C++中的范例).它需要一点习惯,如果一个人习惯于"传统的"OOP模型,但它是值得的.它使我的代码更易于维护和扩展.

我目前正在研究的项目是使用范例,但没有设置系统.但是,我真的很想找到一些可以满足以下要求的系统.从我现在的状态切换到新系统需要花费一些时间,但是我稍后会节省多倍的时间.

要求:

  1. 跨平台
  2. 快速
  3. 适用于C++
  4. 支持跨进程编组

让我详细说明这些要求:

跨平台

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

快速

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

适用于C++

......我想这一点大多是显而易见的.我不介意不使用C++类来实现组件,虽然这将定义有用,并且替代方案必须仍然易于使用,特别是因为最终我打算发布第三方扩展的API.

支持跨进程编组

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

COM会很棒,但它不能完全满足要求1.CORBA也会很棒,但它不符合要求2(即使有最快的ORB).XPCOM可能不符合要求2,并且不适用于MSVC,因此不符合要求1.

有什么想法吗?我的下一步是使用protobufs或类似的东西来推销自己,但我当然希望避免这种情况.

更新

详细说明 - 在此上下文中的音频中断可以低至2-3ms.那个时间甚至不能完全提供给我,因为其他组件需要在那个时间处理,而我的软件本身就包含了另一个需要在那个时间处理的软件.这就是为什么在进程和跨进程编组都需要非常快的原因.

sdg*_*sdg 2

CORBA 肯定是一个答案 - 您应该在基于速度而放弃它之前对其进行测试。

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

祝你好运