最近我正在和我的一个 friend 聊天，他几个月前开始学习 C++ 类(class)(他第一次接触编程)。我们谈到了 C# 和 .NET 的一般话题，他向我指出，他认为所有常见问题(低速、易损坏的字节码等)都“注定要失败”。我在所有这些问题上都同意他的看法，但我没有说这是注定要失败的，只是因为我觉得，随着时间的推移，像 C# 这样的语言可能会变成本地代码(如果微软选择将 .NET 的实现从字节码，JIT 运行时环境，可以像 C++ 程序一样直接编译为 native 代码)。
我的问题是，我要在这里吃午饭吗？我的意思是，这可能需要做很多工作(并且可能会破坏太多东西)，但是并没有某种神奇的障碍可以阻止 C# 代码被本地编译(如果有人想这样做的话)，对吧？曾经有一段时间，C++ 被认为是一种非常高级的语言(它现在仍然是，但不像过去那么多)，但现在它是 Microsoft native API 的基石(与 C 一起)。 .NET 有朝一日可以在这方面与 C++ 处于同一水平的想法对我来说似乎只是时间和努力的问题，而不是语言设计中的一些基本缺陷。
编辑:我应该补充一点，如果 .NET 的 native 编译是可能的，为什么 Microsoft 选择不走那条路？他们为什么选择 JIT 字节码路径？
最佳答案
Java 使用字节码。 C# 虽然使用 IL 作为中间步骤，但总是 编译为 native 代码。 IL 永远不会像 Java 字节码那样被直接解释执行。如果确实需要，您甚至可以在分发之前预编译 IL(提示:如果不这样做，从长远来看性能通常会更好)。
认为 C# 很慢的想法是可笑的。某些 winforms 组件 速度很慢，但如果您知道自己在做什么，C# 本身就是一种非常快速的语言。在这个时代，它通常归结为算法。如果您实现了错误的冒泡排序，语言选择将无济于事。如果 C# 可以帮助您从更高级别使用更高效的算法(根据我的经验，它通常会这样做)，这将胜过任何其他速度问题。
根据您的编辑，我还想再次解释一下(典型的)编译路径。
C# 被编译为 IL。这个 IL 被分发到本地机器。用户运行该程序，然后该程序被 JIT 编译为该机器的 native 代码一次。下次用户在该机器上运行该程序时，他们将运行一个完全原生的应用程序。还有一个 JIT 优化器可能会使事情变得有点困惑，但这就是一般情况。
这样做的原因是允许个别机器进行适合该机器的编译时优化。与将相同的完全编译的应用程序分发给所有人相比，平均而言，您最终得到的代码速度更快。
关于反编译:
首先要注意的是，如果您真的愿意，可以在分发之前预编译为 native 代码。在这一点上，您已经接近与分发 native 应用程序相同的水平。然而，这不会阻止一个坚定的人。
它在很大程度上也误解了经济学原理。是的，有人可能会对您的工作进行逆向工程。但这是假设应用程序的所有值(value)都在于技术。程序员高估代码而低估产品的执行是很常见的:界面设计、营销、与用户的联系以及持续的创新。如果你做对了所有这些，一点点额外的竞争将通过增加你的市场需求来帮助你，同时也会伤害你。如果你做错了，隐藏你的算法也救不了你。
如果您更担心您的应用出现在 warez 网站上，那您就更加误入歧途了。无论如何它都会出现在那里。一个更好的策略是 engage those users .
目前，采用 (imo) 的最大障碍是可再分发框架的规模已经变得庞大。希望他们会在相对较近的版本中解决这个问题。
关于c# - 托管代码(特别是 .NET)会变成 'unmanaged' 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/710247/