跨平台进程内动态库绑定(即轻量级,高性能COM或CORBA)的C ++包装建议 [英] Recommendation for C++ wrapper for cross platform in-process dynamic library bindings (i.e. a lightweight, high performance COM or CORBA)
问题描述
我们正在开发具有插件体系结构的应用程序,以允许该应用程序的使用者提供自己的专有算法。 (我们将基本上有一组解析器,并允许第三方提供它们自己的解析器。)
域空间需要非常高的性能,因此进程外绑定
基本上,我们正在寻找一种简单的跨平台包装器: / p>
- 从相对路径加载库
- 提供特定dll / .so到某些文件的映射配置/名称
- 进行一些初始化并查询库以确保它提供了必要的功能
我认为这实际上只是对loadlibrary()的包装,并且方法调用已导出。我们可以自己编写,但我们宁愿使用现有的代码,因为我们已经掌握了足够的内容。
同样,吞吐量和性能非常重要。
类似的问题是:
COM的跨平台替代方案-这个很接近,但是我们只需要进行过程中-不需要进行过程,而且我们的需求更轻一些重量。
这是针对非托管C ++的-我们无法使用.NET
编辑-我们发现的东西
我们发现 Poco 可以很好地满足我们的需求。作为奖励,此页面是有关C ++开发状态和语言方向的颇受赞赏的评论。 ...
这是Poco提供的一个简单的跨平台包装。确实没有太多,但是仍然可以节省我们的时间和测试。在运行时没有额外的开销。
我认为这也可能有效:
http://pocoproject.org/docs/Poco.SharedLibrary.html
We're developing an application that will have a plug-in "architecture" to allow consumers of the app to provide their own proprietary algorithms. (We will basically have a set of parsers and allow third parties to provide their own as well)
The domain space requires very high performance, so out-of-process bindings are not going to work and we'd rather leave the heavyweight things like CORBA and COM alone.
Basically we're looking for a simple cross-platform wrapper around:
- load library from a relative path
- provide a mapping of the particular dll/.so to some configuration/name
- do some initialization and query the library to ensure it provides the necessary functionality
I think this is really just a wrapping around loadlibrary() and the method calls exported. We can write this ourselves, but we'd rather use existing code as we have enough on our plate.
Again, throughput and performance are very very important.
Similar questions are:
Cross-platform alternative to COM - this one is close, but we want in-process only - no need for out of process and our needs are a little "lighter weight".
C++ Cross Platform Dynamic Libraries; Linux and Windows
This is for unmanaged C++ - we cannot use .NET
EDIT - what we found
We found that Poco works great for our needs. As a bonus This page is a much appreciated comment on the state of C++ development and the language direction...
It was a simple cross platform wrapping that we needed that Poco provides. Really there is not much to it, but still saves us time and testing. No additional overhead during run time.
I think this might also work: http://pocoproject.org/docs/Poco.SharedLibrary.html
这篇关于跨平台进程内动态库绑定(即轻量级,高性能COM或CORBA)的C ++包装建议的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!