继 Jeff 和 Joel 对插件架构的讨论之后。
C++ 中的插件（使用运行时加载的 dll）总是有点麻烦。您必须做大量的基础工作才能启用它们，然后插件也必须用 C++ 编写，甚至通常使用相同的编译器。 COM 对象和 ActiveX 解决了其中一些问题，但也引入了一些自己的问题。
然后，向 C++ 应用程序添加 Python 接口是一项大量的工作。
我是否正确地认为用一种 .Net 语言编写的所有库（或程序集或任何你所说的东西）总是可以从另一种 .Net 语言调用？对象和数据类型可以在它们之间自动传输吗？
据推测，由于所有 .Net 语言也使用 Winforms（或 WPF）作为 gui，因此让插件访问主应用程序的 gui 也相对简单。
抱歉，如果这是一个相当明显的观点，我只是一个老式的 C++ 程序员。但通过 C++/CLI 重用现有 C++ 库的便利性让我相信 C#/.Net 可能值得更多研究。
编辑 - 谢谢，我想讨论插件是否是选择 .Net 的一个原因。能够编写ironpython，同时让我的业务用户能够在 VB 中编写一个简单的插件，技术用户能够在 F# 中制作一些巧妙的东西，而无需我做任何更多的工作，这似乎是从 C++ 切换的一个很好的理由
我是否正确地认为用一种 .Net 语言编写的所有库（或程序集或任何你所说的东西）总是可以从另一种 .Net 语言调用？对象和数据类型可以在它们之间自动传输吗？
是的。在 .NET 中，由于 CTS（提供一组通用数据类型以供所有 .NET 兼容语言使用并确保类型兼容性）和 CLS（定义了所有 .NET 语言编译器必须遵循的一组最低标准），跨语言兼容性成为可能。必须符合，从而确保语言互操作性）。在编译期间，任何 .NET 兼容语言的源代码都会由相应的语言编译器转换为中间语言代码。由于所有 .NET 程序集（EXE 或 DLL）都作为中间语言存在，因此它们可以在它们之间进行互操作。所有 .NET 兼容语言都使用相同的数据类型，并且仅表示为 .NET 类型。因此，无论您在 C# 中使用 int 还是在 Visual Basic .NET 中使用 Integer，在 IL 中它都表示为 System.Int32。 []
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
