C#和C++能否实现高性能代码的互操作？

Question

我们有执行高性能数据处理的遗留C++代码(例如，从硬件设备输入的大量数据，这些数据是以时间敏感的方式处理的，用于显示、转换和传输到二级存储)。

我们对新GUI和新实用程序(现有GUI是C++、MFC和Qt)的C#/.NET感兴趣。当然，对于现有的系统，我们不会向.NET虚拟机发出“语言转换”问题(现有代码都是C++)。

经过大量的研究和书籍，我不确定这是否能有效地完成。可能的方法(我是否遗漏了任何方法？)：

processing)

• Thin

• 重写了.NET中的所有东西(不能发生太多的代码，裸金属设备访问，时间敏感的重算法，用于托管C++/CLI

• 的

• 厚适配器层，用于托管C++/CLI

• )不要使用.NET (管理人员感到非常悲伤)

。

我们对(2)“瘦适配器层”的关注是，如果GUI能够(重新)使用“业务”层中的逻辑(许多属性是算法派生的)，那么如果我们不公开/包装C++类，那么很多GUI逻辑只会在业务层复制现有的C++逻辑。

我们对(3)“厚适配器层”的关注是，用一个C++类包装每个C#类似乎非常繁琐(昂贵)，而且有几本书表明，跨越边界的装箱/取消装箱访问似乎表明这种方法是非常不可行的/禁止的(它的性能限制在普通设计之外)。

如何将新的C#/.NET (GUI)接口在C++实现的深度富类结构之上？

Answer 1

C++/CLI非常适合这一点。托管/非托管转换没有性能问题，因为C++/CLI使用.NET运行时引擎本身使用的优化调用技术来实现高性能方法，例如字符串连接。

当您在.NET和相同数据结构的原生版本之间来回复制数据时，会出现性能问题，但使用使用BSTR的库和使用std::string的库也会遇到同样的问题，而缓慢的操作也同样明显(与P/Invoke不同，P/Invoke试图使这些转换透明，并最终在过程中隐藏性能问题)。

你也可以用一些技巧来克服这一点。例如，与其将std::vector复制到System::Collections::Generic::List中，不如实现直接从std::vector读取的IEnumerator。

当然，如果数据将直接传递回另一个C++函数，则根本没有理由将其转换为托管类型。同样，C++/CLI使保持格式变得容易，其中P/Invoke试图在后台转换所有内容。

总之，“瘦”C++/CLI包装层是您最好的选择。

Answer 2

你对这些约束有正确的认识。跨越边界是昂贵的，您不想为了细粒度的操作而这样做。有多细？那当然要看情况了。

在理想的情况下，您的C++代码被分层到一个rational对象模型中，您可以在该模型上放置一个COM层(或类似的层)，用于更大粒度的操作。例如，与其公开具有5个属性的对象，而且不公开每个属性上的setter/getter对，不如公开一个SetProperties()方法，该方法接受要设置的所有属性的映射。这绝不是您需要注意的唯一情况；它只是一个如何偏向于更大粒度操作的例子。

关于COM -这很好，但当然不需要。使用COM对您强制执行一项规则，因为您需要在COM接口中正式定义操作。如果没有COM提供的正式强制执行，您的团队可能会“欺骗”--并暴露层层之间的许多战术集成点，这可能会导致性能问题。

如果您有扎实的项目管理和优秀的团队成员，那么您可以不依赖COM的形式来执行这些项目标准。在C#中定义您自己的包装类，通过这些类进行所有边界交叉。

底线，我怀疑，是你不会知道准确的决定，直到你玩和测试它。

找几个团队成员，优秀的开发人员，让他们构建两种不同选择的原型。薄还是厚，这些术语的确切含义是由你来定义的。给他们三个星期左右的时间把一些东西放在一起。然后衡量他们的生产力和业绩，并在此基础上做出决定。