c++ - 托管 c++ vs com

Question

嗨，我们有一个 c++ 项目（库），它必须暴露于 .net 语言或可能是其他语言（例如旧 vb，但这不是很重要）。两个选项是为项目编写 COM 包装器或托管 c++ 包装器。选择哪一个？

例如，使用托管 c++ 的一大优势是使用 .net 集合类作为参数传递，而不是在 COM 中使用极其复杂的集合。

Answer 1

术语“COM 包装器”没有多大意义。如果想创建一个 COM 类，没有理由首先创建一个普通的 C++ 类，然后创建一个包装它并模仿它的 COM 类。这是 COM 优于托管 C++ 的一个优势：在托管 C++ 中，您必须创建一个普通 C++ 类（用于非托管客户端，除非您没有）和一个托管包装类（用于托管客户端）。

在我看来，何时应该使用 COM 或托管 C++ 进行互操作的决定因素很简单：

如果您想创建一个全新的非托管类（不是包装器），可以由任何语言的客户端使用，请使用 COM。

如果要创建一个全新的类（不是包装器），在其中混合大量托管和非托管代码，请使用托管 C++。

所以你看，“包装器”这个词不应该出现在你的设计中。包装很烂:)

Answer 2

如果您的 COM 集合非常复杂，您可能需要重新考虑如何处理 COM 集合管理。那里完全不同的问题，但话虽这么说......

您提到旧 VB 不是很重要，这对您的回答比您想象的更重要。旧的 VB 不会说 .NET，但它会说 COM 非常好。如果您预见到必须走这条路，那将是对 COM 方面的重大推动。

我不是托管 C++ 的粉丝，因为它是您可能遇到的最不可移植、难以管理、难以阅读的语言方言。但是，如果您的库中的核心代码足够简单，您可能会通过合理的努力在托管 C++ 中启动并运行它。库越动态，移植到 .NET 管理就越困难。然而...

一旦它在那里，COM 包装器可以让您回到您的 COM 客户端（如旧版 VB），而不会出现太多问题，前提是您在进行移植时做出了明智的选择，并在此过程中保持东西易于包装。

这就是我能说的最迂回的方式（带着极大的痛苦）托管 C++ 可能是你最好的选择，但在放弃那个挑战之前，我会认真对待它。