C ++ / CLI + C ++ Native会提高性能吗？ [关闭]

Question

在我们的项目中，我们有三个模块。 C ++（Native），C ++ / CLI，C＃。 我们使用C ++ / CLI在C＃中使用C ++（Native）代码。 为此我们静态地将C ++（Native）与C ++ / CLI连接起来，现在我们可以使用C ++ / C ++管理的dll。

现在，C ++（Native）中的代码是简单的数学算法（No Win32，不与OS交互）。 当我将静态库与C ++ / CLI链接时，它不会成为托管代码吗？ 意味着它不属于CLR。

在C＃中使用带C ++ / CLI的C ++（Native）静态库是否会提高我的性能？ 我是否可以用C＃本身而不是本机代码来编写代码。

请注意，我们在C ++（Native）代码中广泛使用了标准C ++库的算法，容器和迭代器。

谢谢。

Answer 1

当我将静态库与C ++ / CLI链接时，它不会成为托管代码吗？ 意味着它不属于CLR。

不，不一定。 在C ++ / CLI中，所有托管类型都将编译为MSIL，代码将在CLR下运行。 本机类型可以编译为MSIL或本机机器代码，具体取决于您的编译器选项 ：

• /clr选项生成本机代码和托管代码的混合。
• /clr:pure选项生成一个仅托管程序集，该程序集可以包含编译为MSIL的本机类型。 这基本上类似于使用/unsafe选项编译的C＃代码。
• /clr:safe选项生成一个仅包含本机代码的托管程序集。 这基本上就像没有 /unsafe选项编译的C＃代码一样。

在C＃中使用带C ++ / CLI的C ++（Native）静态库是否会提高我的性能？ 我是否可以用C＃本身而不是本机代码来编写代码。

像所有优化问题一样，答案取决于它。 一方面，本机代码通常比托管代码更快，并且可以更高度优化（例如，使用SIMD）。 另一方面，与混合模式组件相关的性能损失。 C ++互操作实现通常非常快（当然比C＃中的P / Invoke快得多），但如果从编译到本机代码获得的收益不够大，那么它可能仍然不值得。 真正了解的唯一方法是测试这两个选项。

托管代码经常会受到严厉的抨击，特别是来自经验丰富的C ++程序员，但事实是，编写良好的C＃代码可以与同等的本机C ++代码一样快。 这也是一个容易得多 ，以拍摄自己的C ++中的脚，所以如果你有一个开发团队谁是C＃专家，不一定C ++专家，你可能有写得不好的和更慢的C ++代码来结束。 最后，当您的项目的其余部分都在C＃中时，降低的维护成本可能意味着即使是类似的性能也是可以接受的。