COM 的跨平台替代方案
我一直着迷于基于组件的编程（无论是使用 COM、另一个系统，还是仅使用纯 C++ 中的范例）。 如果一个人通常习惯“传统”OOP 模型，那么它需要一些时间来适应，但这绝对是值得的。 它使我的代码更易于维护且更易于扩展。
我目前正在进行的项目正在使用范例，但没有固定的系统。 但是，我真的很想找到某种可以满足以下要求的系统。 从我现在拥有的系统切换到新系统需要一些时间，但以后我会节省很多时间。
要求：
- 跨平台
- 快速
- 与 C++ 配合良好
- 支持跨进程编组
让我详细说明这些要求：
跨平台
基本上，我需要它在 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-3 毫秒。 我什至无法完全利用那段时间，因为其他组件需要在这段时间内处理，而我的软件本身正在包装另一个需要在这段时间内处理的软件。 这就是为什么进程内和跨进程编组都需要非常快的原因。
I've been enamoured with component based programming (be it with COM, another system, or just using the paradigm in plain C++). It requires a bit of getting used to, if one is usually used to the "traditional" OOP model, but it's definetely worth it. It's made my code more maintainable and easier to extend.
The project I'm currently working on is using the paradigm, but no set system. However, I'd really like to find some sort of system I could use with the following requirements. Switching over from what I have now to a new system would take a bit of time, but I'd save a multiple of that time later.
The requirements:
- Cross-platform
- Fast
- Works well with C++
- Supports cross-process marshalling
Let me elaborate on those requirements:
Cross-Platform
Basically, I need it to work on Windows and Mac. Linux would be nice, but is not in any way essential. Also, it really needs to fulfil the other requirements for all platforms. There's a COM for Mac, which would be ideal but it doesn't support requirement 4. Additionally, it must support both GCC and MSVC.
Fast
This is where CORBA unfortunately loses, even though it fulfils the other three requirements. In-process method calls need to be as fast as possible (ideally, like COM), since some of the routines might also be called from an audio interrupt.
Works well with C++
... I guess this one is mostly obvious. I don't mind not using C++ classes to implement components, though that would definetely be helpful, and the alternative must still be easy to use, especially since eventually I intend to release an API for 3rd party extensions.
Supports cross-process marshalling
By that I mean at least being able to serialize the calls. If this is done via code generated from an IDL, that's perfectly fine with me, and I also don't mind implementing the cross-process communication itself.
COM would be great, but it doesn't meet requirement 1 fully. CORBA would be great too, but it doesn't meet requirement 2 (even with the fastest ORB out there). XPCOM might not meet requirement 2, and doesn't work with MSVC so doesn't meet requirement 1.
Any ideas what else is out there? My next step would be to roll my own using protobufs or something similar, but of course I'd like to avoid that.
Update
To elaborate - an audio interrupt in this context can be as low as 2-3ms. That time isn't even available in full to me, as other components need to process in that time, and my software is itself wrapping another piece of software that needs to process in that time. This is why both in-process and cross-process marshalling needs to be extremely fast.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
为了获得最大的广度，我只使用网络服务。 面向服务的方法非常接近面向组件的方法，因为仅公开服务契约（接口），并且客户端不需要了解服务内部工作的细节。
For maximum breadth, I'd just use web services. A service-oriented approach is very close to a component-oriented approach, as only the service contracts (interfaces) are exposed, and no details of the inner workings of the service need ever be known by the clients.
ZeroC 的 ICE http://www.zeroc.com/ 是另一种选择。
对于那些 CORBA 的老前辈来说，Michi Henning 是当时的大师之一。 他现在在 ZeroC 工作。 它是一个开源、跨平台的系统，包括您的所有目标（包括 Linux）。
C++ 只是其中一种语言，ICE 的 C++ 绑定明显优于 CORBA C++ 绑定。
ICE from ZeroC http://www.zeroc.com/ is another alternative.
For those CORBA old-timers, Michi Henning was one of the gurus of the day. He is now with ZeroC. It is an open-source, cross-platform, including all your targets (including Linux), system.
C++ is only one of the languages, and ICE's C++ bindings are significantly better than the CORBA C++ bindings are.
CORBA 肯定是一个答案 - 您应该在基于速度而放弃它之前对其进行测试。
一个明确的替代方案是 XPCOM http://en.wikipedia.org/wiki/XPCOM -缺少MSVC并不意味着不能跨平台。
祝你好运
CORBA would certainly be an answer - you should test it before you dismiss it based on speed.
A definite alternative would be XPCOM http://en.wikipedia.org/wiki/XPCOM - lack of MSVC does not mean not cross platform.
Good Luck
Qt 不应该是一个替代品吗？
http://qt.io
AFAIKT 您至少可以在：
窗户| 苹果电脑| Linux/X11 | 索拉里斯 | 嵌入式Linux |
嵌入式Windows | Green Hills 软件诚信 |
QNX | VxWorks
恕我直言，这就是全部。
Shouldn't Qt be an Alternative?
http://qt.io
AFAIKT you can use it at least on:
Windows | Mac | Linux/X11 | Solaris | Embedded Linux |
Windows Embedded | Green Hills Software INTEGRITY |
QNX | VxWorks
That's quite much IMHO.
为什么您认为 CORBA 不够快？ 您最近测量过东西吗？
CORBA 的现代实现可以在不到 150 us 的时间内进行远程调用。 远低于您的 2 毫秒预算。 CORBA 的现代实现可以将进程内调用优化为基本上两个虚拟函数调用，尽管这通常要求应用程序放弃一些功能（例如拦截器）。即使是在最坏情况下的全功能本地调用也只是几次查找+一些虚拟呼叫，我手边没有号码，但我确信它低于 50 usecs。
查看一些性能数据：
http://www.dre.vanderbilt.edu/统计/性能.shtml
Why do you think that CORBA is not fast enough? Have you measured things recently?
Modern implementations of CORBA can make remote calls in less than 150 usecs. Way below your 2msec budget. Modern implementations of CORBA can optimize in-process calls to basically two virtual function calls, though that usually requires the application to forgo some features (interceptors for example.) Even a full featured in the worst case scenario local calls are a couple of lookups + some virtual calls, I do not have numbers handy, but I am certain it is below 50 usecs.
Check this out for some performance numbers:
http://www.dre.vanderbilt.edu/Stats/performance.shtml
你说 CORBA 会很棒。 我只能假设你从未使用过它。 它是编程的噩梦，并且不提供它所声称的可移植性。 只有现有应用程序已经实现了它，我才会使用它。 然而，我不会因为性能原因而放弃它——我使用过的任何 CORBA 实现都从未遇到过任何性能问题。
You say CORBA would be great. I can only assume you have never used it. It is sprogramming nightmnare, and doesn't offer the portability it claims. I would only use it if an existing application already implemented it. However, I wouldn't chuck it out on performance grounds - I've mnever experienced any performance problems with any of the CORBA implementations I've used.
看看D-Bus（是的，对于windows 也是），它是各种组件框架（CORBA、Gnome Bonobo、KDE 的 DCOM）的现代精神继承者。
如果跨进程编组被证明是一个性能问题，请考虑将繁重的工作转移到共享内存（boost.interprocess 将有助于保持跨平台）。
Take a look at D-Bus (yes, for windows too), which is the modern spiritual heir of various componentry frameworks (CORBA, Gnome Bonobo, KDE's DCOM).
If the cross-process marshalling turns out to be a performance problem, look to move the heavy lifting to shared memory (boost.interprocess will help keep it cross-platform).
看一下AF架构：
“Af-Arch是一套完整的库以及允许开发分布式系统的工具，这些系统专门设计用于解决业务应用程序的问题。”
我知道它适用于linux和windows。 我还知道它有一个非常快的 C API 和 C# 绑定。
Take a look at the AF Architecture:
"Af-Arch is a complete set of libraries and tools which allows to develop distribuited system especially designed to face problems about bussiness applications."
I know it works with linux and windows. I also know it has a very fast C API and C# bindings for it.
我认为你应该看看 VortexLibrary。
它是一个完整的 BEEP 实现，为开发任何点对点应用协议提供了良好的基础。 它已经集成了身份验证（使用 SASL）和安全连接（使用 TLS），两者都是可选的。
Vortex 还包括带有 IDL 编译器的 XML-RPC 配置文件的实现，它应该为您提供编组内容的足够基础......并且最好的是您稍后可以在相同的协议之上提供更具体的协议session，进行二进制传输而不受XML-RPC的限制。
它使用 C 编程，但也可以使用 C++。 目前它正在运行，回归测试确保其在 Linux、Windows 和 MAC 下的功能。
干杯!
I think you should take a look into VortexLibrary.
It is a complete BEEP implementation which provides a good foundation to develop any peer to peer application protocol. It already integrates authentication (using SASL) and secure connections (using TLS), both optionals.
Vortex also includes an implementation of the XML-RPC profile with an IDL compiler which should provide you with the enough foundation for the marshalling stuff....and the best is that you can later provide a more particular protocol, on top of the same session, to do binary transfer without being limited by XML-RPC.
It is programmed with C but also works with c++. Currently it is running, with regression tests ensuring its function under Linux, Windows and MAC.
Cheers!