我目前正在从事一个需要同时在 Mac 和 Windows 上工作的项目。我们对所有应用程序逻辑使用标准的可移植 C++。然而，由于我们希望应用程序在两个平台上都感觉完全原生，因此 GUI 将使用适用于 Windows 的 C#/WPF 和适用于 Mac 的 Objective-C/Cocoa 编写。
但是，对于 Windows 部分，我想知道将 C++ 代码与 C# 结合使用的最佳方式是什么。 C# 是托管的，我知道我们也可以使用托管的 C++。然而，我担心在 CLR 中使用 C++ 可能会引入意想不到的错误，或者我们需要在 C++ 代码中的任何地方放置大量#ifdef WIN32 以使其在 Mac OS X 的托管 CLR 和非托管环境中工作(请注意，我们确实希望放置一些 ifdef，但如果可能的话，我们希望对其进行控制)。那么基本上，将 C++ 代码与 C# 代码一起使用的最佳方法是什么？目前，我正在考虑三种解决方案
1- 将 C++ 编译为 C++/CLI，并直接使用 C# 中的类和函数。
2- 编译 C++ 并将其包装在非托管 win32 dll 中，并使用 DllImport 从 C# 调用它
3- 将 C++ 包装在 COM 包装器中，并使用 .NET COM Interop 将其与 C# 链接
哪种方法最好？或者，如果有更好的解决方案，它是什么？
最佳答案
C++/CLI 对标准 C++ 有一些限制，这些限制并不总是使将标准 C++ 重新编译为 C++/CLI 变得容易。请记住，对于初学者，您必须区分“托管”和“非托管”指针。由于它们使用不同的符号，因此您已经获得了第一组#ifdef。然后你会得到 ref 和 value 类以及所有这些乐趣。
但是，您可以使用 C++/CLI 来弥合 native 代码和 .NET 世界之间的差距。上次我按照你计划做的事情做了一些事情，我使用 C++/CLI 编写了桥接层，它在 .NET 类型和类与本地世界之间进行了必要的翻译和转换工作。 C++/CLI 层显然可以在任何 .NET 语言中使用。
您不能总是使用 (2) - 这在很大程度上取决于您试图在两个世界之间交换的数据类型。 .NET 编码代码非常擅长处理 C POD，但任何更复杂的事情都会遇到问题。
(3) 是矫枉过正恕我直言，并引入了另一个故障点，而且如果您创建了自己的桥接代码，那么您正在执行 .NET <-> COM <-> native 而不是更简单的 .NET <-> native。更不用说您给代码添加了复杂性，这对您所针对的其他操作系统(即 OS X)没有好处。
关于c# - 如何使用带有 WPF C# GUI 的跨平台 C++，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1469947/