cha*_*ley 1 performance c++-cli legacy-code
我们有传统的C++代码执行高性能数据处理(例如,从硬件设备馈送的大量数据,以时间敏感的方式处理,用于显示,转换和传输到二级存储).
我们感兴趣的是C#/ .NET用于新的GUI和新的实用程序(现有的GUI是C++ MFC和Qt).当然,对于现有系统,我们对.NET虚拟机没有"语言翻译"问题(现有代码都是C++).
经过大量的研究和许多书籍,我不确定这是否可以有效地完成.可能的方法(我错过了吗？):
我们对(2)"瘦适配器层"的关注是,如果GUI可以(重新)使用"业务"层中的逻辑(许多属性是算法派生的),那将是很好的,所以如果我们不公开/包装C++类,很多GUI逻辑只会复制业务层中的现有C++逻辑.
我们对(3)"厚适配器层"的担忧是用C#类包装每个C++类似乎非常繁琐(昂贵),并且有几本书表明跨越该边界的装箱/取消装箱访问似乎表明这种方法是不可行的/禁止(它的性能超出了琐碎的设计).
如何在C++中实现的深层次类结构之上界面新的C#/ .NET(GUI)？
C++/CLI非常适合这种情况.托管/非托管转换没有性能问题,因为C++/CLI使用.NET运行时引擎本身使用的相同优化调用技术来实现字符串连接等高性能方法.
当您在.NET和相同数据结构的本机版本之间来回复制数据时会出现性能问题,但是您会遇到同样的问题,例如使用使用BSTR的库以及使用的BSTR std::string,以及操作缓慢同样显而易见(与P/Invoke不同,P/Invoke试图使这些翻译变得透明,并最终隐藏过程中的性能问题).
你也可以使用一些技巧来克服这个问题.例如,不是将a复制std::vector到a中,而是System::Collections::Generic::List实现IEnumerator直接从中读取的std::vector.
当然,如果数据只是直接传递回另一个C++函数,那么就没有理由将其转换为托管类型.同样,C++/CLI使得格式保持简单,其中P/Invoke尝试转换背后的所有内容.
总之,"瘦"C++/CLI包装层是您最好的选择.
| 归档时间： |
|
| 查看次数： |
2265 次 |
| 最近记录： |