我现有的C ++ lib包含许多不同的类一起工作。一些示例用法应该包括将一个类的实例传递给另一个类的构造函数/方法。
我计划使用C ++ / CLI为这些C ++类提供C＃绑定，因此我不必移植整个C ++代码。
我已经可以通过创建另一个隐藏用户现有C ++代码中所有类的类，以“Facade”的方式执行此操作。但是，我想要的是向用户提供具有相同方法签名的相同类。
对此有任何指导或建议吗？
PS。我已经看了一些现有的开源C＃到C ++绑定项目。但他们似乎使用了许多不同的方法来做到这一点，我真的不明白它。
答案 0 :(得分：5)
这很大程度上取决于你的课程因素。
在我所做的工作中，我尝试将我建模的C ++类视为隐藏的实现细节，并将其包装到适当的C ++ / CLI类中。在大多数情况下，我可以通过拥有非特别精细的托管接口来逃避这种情况。当您的实现涉及直接实现底层C ++代码的每个细节时，您将最终得到一个非常“繁琐”的接口，这将涉及托管/非托管转换中的相当大的成本。
特别是，如果您的非托管C ++类使用stl，尤其是stl集合类型，当您发现通过stl集合的每次迭代都涉及多个托管/非托管转换时，您可能会发现自己感到不愉快。我有一个图像解码器，它使用stl很重，它就像狗一样跑。将#pragmas放在访问stl类型的代码周围的明显修复没有帮助。我发现它确实起作用的是将所有这些隐藏在一个基于句柄的C接口中，该接口隐藏了铁幕后面的所有C ++ - 主义。没有stl暴露在任何地方意味着它被允许作为非托管代码存在。
我认为你最大的问题将是你如何处理集合（如果你使用任何集合）作为C ++集合哲学和.NET集合理念不匹配。我怀疑您将花费大量时间将适应类的.NET集合映射到类/类型的C ++集合。
修改 Here's a blog article我前段时间曾写过这个问题。它使用托管C ++方言，而不是C ++ / CLI，但问题是相同的。
答案 1 :(得分：1)
我曾经仅使用[DllImport]属性与C＃进行了C ++绑定。如果你没有在这里说过任何STL问题，并且你的lib很简单（例如，作为一个DLL），我想这是绑定C ++和C＃的最简单方法。
MSDN上的简单示例：http://msdn.microsoft.com/en-us/library/aa984739(VS.71).aspx