结合 C++ 和 C#

Posted 2023-02-22

【中文标题】结合 C++ 和 C#

【英文标题】：Combining C++ and C#

【发布时间】：2010-03-28 12:42:47

【问题描述】：

将 C++ 和 C# 结合起来是一个好主意吗？还是会带来任何直接的问题？

我有一个应用程序需要一些部分是 C++，而一些部分是 C#（为了提高效率）。在 C# 中使用本机 C++ dll 的最佳方法是什么？

【参考方案1】：

问题显然是如何将他自己的 C++ 代码集成到他的 C# 解决方案中，而不仅仅是使用什么属性来从 win32 API 调用现有函数。即使答案已经被接受，我认为它是不完整的，应该适用以下内容。

是的，在任务可以运行得更快、使用更少的资源以及在某些情况下访问 .net 框架中不可用的方法的情况下，这是一种常见的做法。

如果您的目标是提高效率，您需要编写本机非托管 C++ 库，您将在 Visual Studio 中创建一个新的非托管 C++ 项目（编译为 dll 库）并引用此库来自您的 C# 项目。

在您的情况下，您可能正在编写一个非托管 C++ 库，以下适用。

至于您询问的任何直接问题，它会影响部署和混淆。

部署：请记住，您构建的 C# DLL 将在任何 CPU，32 位和 64 位，但这个新的 本机和非托管 C++ 库将 强制你的程序要么 32 或 64 特定。

这是您将配置的内容 在您的 Visual Studio 配置管理器中，以及 将在编译时处理 到时候，你会为 C# 选择 AnyCPU 程序集和新的非托管 C++ 库（将在它自己的项目中），您将拥有 从win32或x64中选择。

所以你现在将有 2 个设置，它是 推荐的最佳实践 单独的设置，一个用于 32 和 另一个 64 的。或者从 32 位开始 支持下降非常快，你 只能专注于 64 位。

此外，您的库最终可能会引用 Visual Studio 提供的 VC++ 可再发行组件，您可能必须将其包含在您的部署中，尽管它的某些版本包含在许多操作系统中，但我发现它很少与我编译时使用的相同最好将它与您的应用程序一起部署以确保。如果缺少这个包，目标机器的 eventviewer->application log 中会出现 SideBySide 异常。

要捕获和处理从非托管代码抛出的异常，唯一有效的捕获是空捕获，即在 catch() 之后的括号中没有异常类型的捕获。因此，您可以在其中包装对非托管代码的调用以处理从非托管代码内部抛出的所有非托管异常，如果您放置像 catch(Exception) 这样的 .net 类型，它只会跳过它。在托管代码中捕获非托管异常的唯一方法就是采用这种格式。

    try
    
       //call unmanaged code
    
    catch
    
       //handle unmanaged exception
    

混淆：从 C# 完成的任何方法调用现在正在调用 现在将排除非托管代码 从自动重命名。另一方面， 如果您的非托管 C++ 库需要 从您的托管调用方法 组件，这些将需要 手动排除重命名，以便 对 C++ 库调用可见 他们。

如果您只需要调用 Windows 等知名 C++ 库，则无需创建新的非托管 C++ 项目，只需使用上一个答案中建议的 [DllImport()] 属性即可。在这种情况下，您可以查看此参考http://www.pinvoke.net/

【讨论】：

catch and handle an exception thrown from unmanaged code -- 我认为这必须改写，catch without exception 类型规范意味着只捕获异常。没有简单的方法来进行特定的处理，但是捕获可以让您的 C# 应用程序运行...另请参阅 .net - Can you catch a native exception in C# code? - Stack Overflow 和 CA2102: Catch non-CLSCompliant exceptions in general handlers

【参考方案2】：

是的，在您的产品中使用 C# 和 C++ 非常普遍，而且是个好主意。

有时您可以使用托管 C++，在这种情况下，您可以像使用任何其他 .NET 模块一样使用托管 C++ 模块。

通常，您会在 C# 中做所有可以做的事情。对于您需要在 C++ 中执行的部分，您通常会创建一个 C++ DLL，然后从 C# 调用该 DLL。参数的编组是自动为您完成的。

以下是将 DLL 中的 C 函数导入 C# 的示例：

[DllImport("user32", CharSet=CharSet.Auto, SetLastError=true)]
internal static extern int GetWindowText(IntPtr hWnd, [Out, MarshalAs(UnmanagedType.LPTStr)] StringBuilder lpString, int nMaxCount);

【讨论】：

那是 .NET 的广告吗？跨平台兼容性、连接问题、学习曲线等如何？

学习曲线？我想您在尝试组合语言时了解 C++ 和 C# 的基础知识。跨平台？很明显，用 C++ 编写跨平台代码要困难得多，但有可能。与 C# 结合使用似乎更容易 - 更高级别的代码可以决定在特定平台上加载和使用哪些 C/C++ 部分。

我当然希望你没有使用 C++ 来定位 PIC！

@Harry "` 很明显，用 C++ 编写跨平台代码要困难得多，但有可能`" ????奥利？这在什么方面很明显？

因为手动内存管理依赖于平台。然后，C# 中的 GC 做了一些重要的工作。相反，手动完成工作似乎更难。 C# 项目的配置很简单。甚至为 C++ 配置基本的编译器选项也并非易事。将目标架构从 x86 更改为 x64 是在 C# 项目中切换一个选项。当然，我们在 C# 中也有平台相关的代码，但更基本的东西几乎是平台无关的。 C# 还有许多比宏更现代的智能功能。

【参考方案3】：

有关 C# 与 C++ 差异以及合并它们的可能问题的其他信息：

C# 是解释型的，类似于 Java。 C++ 被编译为本机二进制文件。这有几个不同之处，在以下几点中进一步解释。即使使用 JIT，也需要翻译的初始阶段。 平台兼容性：C#，作为解释和 Microsoft 产品，它在 Windows 上运行良好，在 Linux 上也能正常工作，这要归功于一个伟大的项目Mono，但在其他平台（android、ios ，其他。）如果你想为不支持操作系统的嵌入式软件编写软件，或者编写操作系统本身，你大多“不能”使用 C#。只要您拥有编译器（通常就是这种情况），C++ 就完全是跨平台的。 解释代码通常比二进制代码慢一个数量级[1]。这是在 C# 中链接 C++ 的原因之一。 二进制与中间代码：中间代码适用于特定架构上可用的任何解释器，C++ 需要为每个架构重新编译。 学习曲线：为了将两种语言结合起来，开发人员需要学习多种语言，这增加了学习时间。也更难找到两种语言的专家。 实时：似乎很难用 C# 想象（硬）实时条件。 使用 C# 代码（安全关键软件）可能无法获得某些质量认证。

将它们结合起来是个好主意吗？

这可能取决于您的项目。 对于 Windows（甚至 Linux）上的大型 HMI 开发，这可能会缩短您的开发时间。但是，其他软件要求可能会限制使用 C# 来支持 C++（或 ASM、C、..）。

---

[1] 我多次读到解释代码在某些情况下甚至比二进制代码还要快，这是由于一个误解： 为了方便，解释器实现了几个函数，所以当你调用（例如）sort()时，实际上它调用了这个函数的二进制实现。如果这个函数得到了很好的优化，最后的时间可能会更快，但这只是因为所有运行在二进制文件中并且解释的组件与排序所需的所有时间相比是最少的。另一方面，如果你用两种语言编写完整的逻辑，二进制版本总是会明显更快。原因很简单：解释器是一个二进制文件，除了你的代码之外，它还运行所有语言框架。

【讨论】：

Jit 与解释型不同。 Jit 可以编译成机器码。

Jit 是运行时编译的 -> 也需要时间。它不工作，比方说 PIC16F，它不能被认证，等等。

负分是因为什么原因？

主要是因为您的答案中几乎所有内容都是错误的。 JIT 不是解释。 C# 可以预先完全编译而不使用 JIT，C# 可以在没有 Mono 的情况下在 Linux 上运行，C# 可以从任何编辑器开发，C++ 不能比 C# 在实时方面做得更好，因为两者都运行在分时操作系统上，以及 C#代码可以通过医疗和航空航天应用的认证。

JIT 不是解释，而是在运行时翻译，对吗？ C# 不能在没有 Mono 的 Linux 上开发，所以不是真正的跨平台，对吗？ C++ 可以进行硬实时，例如通过在 RTOS 上运行；您是否尝试在 RTOS、MCU 或驱动程序上运行 C#（我为 C++ 做过）？请告诉我任何 C# 中的安全关键软件。并不是说 C# 不好，但它也有它的局限性。