将概念分开可能是个好主意。
首先,C++ 是一门语言,它没有具体说明应该针对什么平台。原则上,直接的 C++ 代码可以编译为本机 x86 汇编程序、Java 字节码、MSIL 或您想想到的任何其他内容。我相信 Adobe 最近制作了一个生成 Flash 字节码的 C++ 编译器。
其次,由于典型的优柔寡断,微软创建了两种针对 .NET 的 C++ 派生语言。首先,他们制作了“C++ 托管扩展”。然后他们认为它糟透了,抛弃了它,并试图假装它从未存在过。
现在,他们对 .NET 风格的 C++ 的最佳选择称为 C++/CLI,但它不是 C++。它以多种非标准方式扩展和更改语言。(而且我相信 C++ 标准委员会要求他们更改名称以避免混淆。但他们没有)
Visual Studio 2005 和更新版本支持 C++/CLI。(在“添加项目”中,它们列在 Visual C++ -> CLR 下)
然而(你没想到这么简单,是吗?),微软又做了一次。在指定 C++/CLI(这实际上是一种设计合理的将 C++ 与 CLI 集成的尝试)之后,他们意识到几乎没有人使用它!事实证明,即使是 C++ 程序员,在 .NET 中工作时通常也更喜欢使用 C#,否则更喜欢使用适当的原生 C++。
所以现在,他们专注于让原生C++ 和 .NET 之间的互操作更简单、更强大。但是,C++/CLI 不太可能消失。它有效,在某些情况下它很有用。这不是他们最初希望的 C++ 杀手。
Visual Studio(自始至终)还支持本机 C++ 应用程序,编译为 x86 机器代码,不受 .NET 污染。这些列在 Visual C++ -> Win32 下的“添加项目”对话框中。
因此,如果您想学习 C++,您有两个选择: 学习 C++/CLI,这将您限制为仅限 MS 的语言,是的,生成 MSIL 而不是本机机器代码,并且需要 .NET 才能运行,而且通常不是值得费心,因为如果您仍然要依赖 .NET ,为什么不使用 C# 编写呢?
或者学习正确的 C++,它与 .NET 完全分离,不能直接引用 .NET 程序集。
关键的要点是它们是不同的语言。要么编译为 C++/CLI,这意味着编译器将允许你引用 .NET 程序集,并生成 MSIL 代码,要么编译为 C++,在这种情况下,.NET 世界不存在。
最后,请注意。尽管我上面的措辞(“正确的 C++”和“不受 .NET 污染”),C++ 并不是“更好”。在许多情况下,它也不是更快。C++ 有可能更快,但它更多地取决于程序员。
C# 编译器会将几乎任何东西都变成相当高效的代码。另一方面,C++ 充满了陷阱,会使您的代码比等效的 C#慢。
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx及其引用的博客文章值得任何对用两种语言编写的类似代码的性能感兴趣的人阅读。
只有一个领域 C++ 应用程序会始终更快,那就是启动时间。.NET 应用程序可能必须加载 .NET 框架并 JIT MSIL 代码,而本地应用程序...刚刚启动。
但除此之外,假设 C++ 会更快可能是错误的。可以,因为它给了你更多的控制权。但通常,这只是意味着编译器无法将您从您在代码中创建的低效率中拯救出来。