是 C++ 转换成MSIL？
我长期以来一直是 C# 和 .Net 开发人员，并且一直在考虑学习 C++。
我一直在思考这个问题的主要原因之一是，C++ 比使用 .Net 框架的应用程序要快得多。 但我是否正确地假设，如果我在 Visual Studio 中编写 C++ 应用程序，和/或在 C++ 应用程序中引用 .Net 库，则 C++ 会在 MSIL 中转换（就像 C# 一样），因此我会失去任何好处从里面编码？
所以我的问题实际上是这样的：引用 .Net 程序集的应用程序的 C++ 组件是以“传统”方式编译的，还是编译到 MSIL 中的？
I have been a long time C# and .Net developer, and have been playing with the idea of learning c++.
One of the primary reasons I have been thinking about this, is how much faster C++ can be over apps using the .Net framework. But am I right in assuming that if I write a C++ app in Visual Studio, and/or reference .Net libraries in a C++ application that, that C++ is converted in MSIL (just like C#) - and therefor I'd loose any benefit from coding in it?
So my question is really this: are C++ components of an application referencing .Net assemblies compiled in the "traditional" way, or comiled into MSIL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
嗯，事情比这更复杂一些。
实际上有两个完全不同的支持 .NET 的 C++ 版本。
旧的 C++ 托管扩展是 Visual C++ 2002/2003 中唯一可用的选项。 它可以在较新的编译器中的选项 /clr:oldSyntax 下使用。 它有点笨拙，因为它努力与标准 C++ 集成，因此所有新关键字（而且有很多）都以双下划线等为前缀。该编译器生成的代码是本机代码和 MSIL 代码的混合体，称为 IJW“it只是有效”。
新语言称为 C++/CLI，是 Visual C++ 2005 及更高版本中提供的一种全新语言。 最重要的是，它支持多种代码生成模式。
/clr 选项再次生成本机代码和 MSIL 代码的 IJW 混合体。
/clr:pure 会生成仅托管程序集，尽管它可能会将本机类型转换为相应的 .net 结构。 因此，该代码可能不是类型安全的，并且可以使用指针算术，与带有 /unsafe 的 C# 非常相似。
最严格的选项是 /clr:safe，它生成类型安全、可验证的仅 MSIL 程序集，就像 C# 编译器所做的那样（即没有 /unsafe）。
有关 MC++ 和 C++/CLI 之间的差异，请参阅 wikipedia。
有关编译器开关的说明，请参阅 MSDN。
附言。 .NET 字节码称为 MSIL（Microsoft 中间语言）或 CIL（通用中间语言）。 MIL 可以代表媒体集成层，WPF 和 Vista 桌面窗口管理器使用的未记录的低级库。
Well it's a bit more complicated than that.
There are actually two totally different versions of .NET-supporting C++.
The old one, Managed Extensions for C++, was the only option available in Visual C++ 2002/2003. It's available in newer compilers under the option /clr:oldSyntax. It's kinda clumsy as it tries hard to integrate with standard C++, so all new keywords (and there's lots of them) are prefixed with double underscores, etc. Code generated by this compiler is a mixture of native and MSIL code, dubbed IJW "it just works".
The new one, called C++/CLI, is a clean new language available in Visual C++ 2005 and newer. Most importantly, it supports several modes of code generation.
The /clr option again generates a IJW mixture of native and MSIL code.
/clr:pure results in a managed-only assembly, although it may translate native types into corresponding .net structures. The code therefore may not be type-safe and can use pointer arithmetic, pretty much like C# with /unsafe.
And the strictest of options is /clr:safe, which produces type-safe, verifiable MSIL-only assembly, exactly like C# compiler does (without /unsafe, that is).
For differences between MC++ and C++/CLI, see wikipedia.
For description of the compiler switches, see MSDN.
PS. The .NET byte-code is called either MSIL (Microsoft Intermediate Language) or CIL (Common Intermediate Language). MIL can stand for Media Integration Layer, the undocumented low-level library used by WPF and Vista Desktop Window Manager.
将概念分开可能是个好主意。
首先，C++ 是一种语言，它没有指定任何关于目标平台的信息。 原则上，直接的 C++ 代码可以编译为本机 x86 汇编程序、Java 字节码、MSIL 或任何您想想到的东西。 我相信 Adobe 最近制作了一个 C++ 编译器，可以生成 Flash 字节码。
其次，由于典型的优柔寡断，微软创建了两种针对 .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++ 会更快可能是错误的。 它可以，因为它给你更多的控制权。 但通常情况下，这仅仅意味着编译器不太能够帮助您避免代码中造成的低效率问题。
It's probably a good idea to keep the concepts separate.
First, C++ is a language, and it doesn't specify anything about what platform should be targeted. In principle, straight C++ code could be compiled to native x86 assembler, Java bytecode, MSIL or anything else you care to think of. I believe Adobe recently made a C++ compiler which generates Flash bytecode.
Second, with typical indecisiveness, Microsoft has created two C++-derived languages targeting .NET. First, they made the "managed extensions for C++". Then they decided it sucked, ditched it and tried to pretend it never existed.
Now their best bet for .NET-style C++ is called C++/CLI, but it is not C++. It extends and changes the language in a number of nonstandard ways. (And I believe the C++ standard committee requested that they change the name to avoid confusion. But they didn't)
Visual Studio 2005 and newer supports C++/CLI. (in "Add project", they're listed under Visual C++ -> CLR)
However (you didn't think it was that simple, did you?), Microsoft has done it again. After specifying C++/CLI, which is actually a reasonably well-designed attempt at integrating C++ with CLI, they realized that virtually no one uses it!
Turns out that even C++ programmers generally prefer to use C# when they're working in .NET, and proper, native C++ otherwise.
So now, they're focusing on making interop between native C++ and .NET simpler and more powerful. However, C++/CLI isn't likely to go away. It works, and in some cases it's useful. It's just not the C++-killer they originally hoped for.
Visual Studio (since forever) also supports native C++ applications, compiled to x86 machine code, untainted by .NET. These are listed in the "Add Project" dialog under Visual C++ -> Win32.
So if you want to learn C++, you have two choices:
Learn C++/CLI, which limits you to a MS-only language which yes, generates MSIL instead of native machine code, and requires .NET to run, and generally isn't worth the bother because if you're going to take a dependency on .NET anyway, why not write in C#?
Or learn proper C++, which is completely separate from .NET and can't directly reference .NET assemblies.
The key takeaway point is that they're separate languages. Either you compile as C++/CLI, which means the compiler will allow you to reference .NET assemblies, and will generate MSIL code, or you compile as C++, in which case the .NET world doesn't exist.
And finally, a note of caution. Despite my wording above ("proper C++" and "untainted by .NET"), C++ isn't "better". In many cases, it is not faster either. C++ has the potential to be faster, but it depends a lot more on the programmer.
The C# compiler will turn pretty much anything into reasonably efficient code.
C++ on the other hand, is full of pitfalls that will make your code slower than the equivalent C#.
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx and the blog posts it references are worth a read for anyone curious about the performance of similar code written in the two languages.
There is only one area where C++ applications will be consistently faster, and that's in startup time. a .NET application may have to load the .NET framework and JIT the MSIL code, where a native application... just starts.
But other than that, it is probably a mistake to assume that C++ will be faster. It can be, because it gives you a bit more control. But usually, that just means the compiler is less able to save you from the inefficiencies you create in your code.
此是关于托管与非托管 C++ 的非常好的（如果已过时）讨论。
简而言之，C++ 可以是托管的（编译为 MIL）或非托管的（编译为本机代码）。
This is a pretty good (if dated) discussion of managed vs unmanaged C++.
In a nut shell, C++ can be either managed (compiled to MIL) or unmanaged (compiled to native code).
无论您想要学习 C++ 的原因是什么，了解更多语言总是好的，因为它可以拓宽您的思维，因此学习 C++ 本身就是一堂宝贵的课。
使用 C++，您可以将其作为 .NET 应用程序 C++/CLI 或本机运行。 它只是 Visual Studio 中的编译器开关，但两者之间存在很多语法差异。 我个人认为学习这两种风格是有用的。
在项目中选择哪个取决于需求，例如，如果您的程序需要与其他托管模块（例如用 C# 编写的模块）交互，最好使用 C++/CLI 以避免托管代码和非托管代码之间的切换开销。
Regardless of your reasons for wanting to learn C++ it is always good to know more languages because it broadens your mind so learning C++ is a valuable lesson in itself.
With C++ you can either run it as a .NET application C++/CLI or native. It is just a compiler switch in Visual Studio however there are quite a lot of syntax differences between the two. I personally think learning both flavors is useful.
Which to choose in your projects depends a bit on the requirements e.g. if your program needs to interact other managed modules like modules written in C# it is preferable to use C++/CLI to avoid some overhead switching between managed and unmanaged code.
C++ 组件无法轻松引用 .Net 程序集（您需要使用 COM）。 托管 C++ 被编译为 CIL，并且具有与 C# 相同的性能配置文件。
对于大多数代码来说，对于相同级别的优化，C++ 大约快 10%，但是 C# 需要一半的时间来编写和调试，因此在相同的时间内，我认为您可以实施的优化将使 C# 更快...
C++ components cannot easily reference .Net assemblies ( you need to use COM) . Managed C++ is compiled into CIL and has the same performance profile to C#.
C++ is about 10% faster for the same level of optomization for most code however C# takes half the time to write and Debug so for the same amount of time i would argue the optomizations you can put in place would make C# faster...