最近我和一位几个月前开始上C++课程的朋友(他第一次接触编程)谈话.我们总体上讨论了C#和.NET的主题,他向我指出,他觉得它对于所有常见问题(低速,易碎的字节码等)都是"注定要失败的".我在所有这些问题上都同意了他,但我拒绝说它注定要失败,只是因为我觉得,像C#这样的语言可能会成为本机代码(如果微软选择改变.NET的实现方式)字节码,JIT运行时环境直接编译为本机代码,就像你的C++程序一样).
我的问题是,我出去吃午饭吗？我的意思是,它可能需要做很多工作(并且可能会破坏太多东西),但是没有某种类型的魔法障碍阻止C#代码本地编译(如果有人想这样做),对吧？曾经有一段时间,C++被认为是一种非常高级的语言(它仍然是,但不像过去那么多),但现在它已成为微软原生API的基石(连同C).在某种程度上,.NET在某种程度上与C++处于同一水平的想法似乎只是时间和精力问题,而不是语言设计中的一些根本缺陷.
编辑:我应该补充一点,如果.NET的本机编译成为可能,为什么微软选择不去那条路？为什么他们选择了JIT字节码路径？
Java使用字节码.C#虽然使用IL作为中间步骤,但始终编译为本机代码.IL永远不会像Java字节码那样直接解释执行.如果你真的想要,你甚至可以在分发之前预编译IL(提示:如果不这样做,性能通常在长期内更好).
C#很慢的想法是可笑的.一些winforms组件很慢,但是如果你知道你在做什么,C#本身就是一种非常快速的语言.在这个时代,它通常归结为算法无论如何; 如果您实施错误的冒泡排序,语言选择将无法帮助您.如果C#帮助您使用更高级别的更高效算法(根据我的经验,通常会这样做),这将胜过任何其他速度问题.
根据您的编辑,我还想再次解释(典型的)编译路径.
C#编译为IL.此IL分发给本地计算机.用户运行该程序,然后该程序被JIT编译为该机器的本机代码一次.下次用户在该计算机上运行程序时,他们正在运行完全原生的应用程序.还有一个JIT优化器可能会让事情变得混乱,但这就是一般情况.
这样做的原因是允许单个机器进行适合该机器的编译时优化.平均而言,如果您将相同的完全编译的应用程序分发给每个人,则最终会得到更快的代码.
关于反编译:
首先要注意的是,如果您真的想要,可以在分发之前预编译为本机代码.此时,您将接近与分发本机应用程序相同的级别.但是,这不会阻止一个坚定的个人.
它在很大程度上也误解了经济学.是的,有人可能会对您的工作进行逆向工程.但这假设应用程序的所有价值都在技术中.程序员高估代码的价值非常普遍,并且低估了产品的执行价值:界面设计,营销,与用户的联系以及持续的创新.如果你做到了这一切,那么一点额外的竞争将通过在你的市场中增加需求来帮助你.如果你做错了,隐藏你的算法将无法拯救你.
如果你更担心你的应用程序出现在warez网站上,那你就更加误导了.无论如何它会出现在那里.更好的策略是吸引这些用户.
目前,采用(imo)的最大障碍是可再分发的框架已经变得庞大.希望他们能够在相对接近的版本中解决这个问题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 