编译器和解释器的区别

实例一：

　菜鸟经常将编译器和解释器弄混淆，无奈之下，于是向高手请教。

　　高手说：

“

　　解释器是一条一条的解释执行源语言。比如php，postscritp，javascript就是典型的解释性语言。　　

　　编译器是把源代码整个编译成目标代码，执行时不在需要编译器，直接在支持目标代码的平台上运行，这样执行效率比解释执行快很多。比如C语言代码被编译成二进制代码（exe程序），在windows平台上执行。

”

 

　　菜鸟说：“我还是不明白，能给个形象的比喻么？”

　　高手说：“给你讲个故事。”

　　母亲打电话给儿子说：“你爸最近身体不好，家里人少不热闹”。

      儿子想，对啊，爸年纪大了，身体不好，买点牦牛骨髓壮骨粉不错，于是儿子就去超市买了牦牛骨髓壮骨粉。

　　儿子又想啊，最近黄金搭档很火，买点给爸试试。于是儿子又去买了黄金搭档。

　　从超市回来后，儿子又寻思母亲说的“家里不热闹”，嗯，家里的小皇帝自从上寄宿学校后就比较少回来，估计是老人家想孙子了。儿子于是给上高中的儿子打了个电话，让他周末回来看看。

　　

　　母亲打电话给女儿说：“你爸最近身体不好，家里人少不热闹”。

　　女儿就想，应该给爸做点什么呢？于是她拿出张纸开始罗列条目，先写上了壮骨粉和黄金搭档。然后，想着让老人家看看外孙应该不错，于是就在纸上加上了一句，一家人回爸妈那里看望看望。最后纸上就写着：

　　1.壮骨粉和黄金搭档

　　2.一家人去看望爸妈

      女儿见到女婿后，就将这张纸上的信息编成短信发给了工作的女婿。

　　女婿一看就明白了，下班后先去超市买了补品，然后开车回家带着妻儿就去看望岳父岳母了。

 

      想到什么了吗？

　　菜鸟说：

　　我这样说不知道对不对：儿子就像是解释器，是想到一点做一点。女儿就像编译器，女婿就像平台，女儿听完后，在纸上罗列出所有要做的事情，女婿就按着指示办事了。

　　高手说：

　　就是这样的。儿子对于母亲的话是一条一条执行，女儿是将母亲的话整个翻译成平台能理解的目标语言--短信，整个由女婿直接执行。后者的执行效率会更高。

 

　　从功能上看，解释器和编译器确实不一样。

　　然而，从流程和结构上看，二者却非常相似。

　　儿子和女儿听到母亲的话以后，都是从两个方面来思考：老人的身体和老人对小辈的思念。以此为据，儿子和女儿都做出了自己的决定。只不过一个直接去做了，另一个却将所要做的事情翻译成另一种载体--短信--给存储起来。

      解释器和编译器也是如此，读入源语言后，解释器和编译器都要进行词法分析、语法分析和语义分析，之后，二者开始有所分别。解释器在语义分析后选择了直接执行语句；编译器在语义分析后选择将将语义存储成某一种中间语言，之后通过不同的后端翻译成不同的机器语言（可执行程序）。如下图所示：

　　总之，解析器和编译器它们在功能上是不一样的，然而从结构上看却有诸多相同，而且在开发时也并没有本质上的差别，这也是很多人将二者混淆的原因之一。究竟是开发解析器还是编译器？只需要依据功能上的实际需要来做出决定就ok了。

 

实例二：

来福与旺财的养牛场

来福和旺财有一个养 牛场。本来养牛不是一件太难的事情，但是偏偏他俩养的牛都有特别的怪癖。奶牛阿圆只吃切成圆形的牧草，而奶牛阿方和阿三（印度来的？）分别只吃切成正方形 和三角形的牧草。如果来福和旺财拿不和奶牛性格的草去喂食，阿X们不但不产奶而且还会鄙视来福和旺财。

于是来福和旺财分别有了自己的主意

来福的方案：
来福发明了三套大型碾碎机：圆圆碾碎机，方方碾碎机和三三碾碎机。每天收割了牧草，就分别放到这三套机器里碾碎给三头奶牛吃。但是一旦被碾碎了，这堆草就只能给某一头牛吃了。很明显阿方是不会吃给阿圆准备的草的。而且来福每天都要操作这三台机器，觉得比较麻烦。



旺财的方案：
旺财在考察了来福的方案后，发现每天操作三台机器真的很麻烦，而且有时有的牛吃不完，有的牛不够吃时，还不能在奶牛之间调配碾碎了的牧草。所以旺财有了不同的想法：口罩型碾碎机。


就像在图上看到的，旺财给每头奶牛装配了一台口罩碾碎机，所以三头牛完全可以在一个槽里吃草了，在吃之前口罩会自动把牧草碾碎成适合该牛食用的类型。旺财就轻松了，他每天只需要割割草就行了。

但是旺财被鄙视了？？？

是的，被来福鄙视了。来福观察后发现，旺财的口罩碾碎机的效率很低（因为比较小嘛）。阿圆食量大，吃来福的圆圆碾碎机的食物一个小时就饱了，但是戴着口罩吃的时候要吃十个小时！所以来福认为旺财的口罩碾碎机虽然省事，但只能喂喂小牛，完全不适合食量大的牛。

旺财也觉得这样做有问题，但他不想回到来福方案上，他改进了口罩方案：牧草预切割机。


呵呵，看到预切割做了什么吗？它把牧草割得小了一些，所以需要口罩碾碎机做的事情就少多了。（当然口罩碾碎机也要作适当改进适合预切割后的牧草，所以图上用蓝色表示）阿圆以前用口罩不是要吃十个小时吗，现在两三个小时就可以了。

编译器与解释器

好的，谢谢你有耐心看到这里，经过上面那个不太恰当的例子，相信你已经相当的糊涂了。那么我们试着回到技术方面来。
在上面的例子中
牧草 ＝ 我们的各种编程语言，C/C++/C#, Java, Pascal, PHP, Python, Perl, Java Script等等
切割机 ＝ 各种编译器
奶牛 ＝ 各种CPU（不要告诉我Intel和AMD哦），比如x86，ARM，MIPS等等
那你应该知道了为什么奶牛会有吃不同形状牧草的嗜好了，这个奇怪的比喻是为了表示不同的CPU接受的不同的机器语言。

对应上面的奶牛图，编译器的图是这样的



源代码被编译成机器码，在CPU上运行。

而解释器是这样的



用解释器很方便，只需要直接“运行”就好了，不用像C那样有编译链接的工序。

为什么说这些语言是跨平台的？因为你写了程序以后，如果这个平台上有这种语言的解释器，只需要拿到这个平台上直接运行就可以了。你可以理解为：解释器是在“一边编译，一边运行”，它只是把以前程序员手工做的编译过程放在了运行程序的时候进行。

为什么我们一般说解释器的效率比较低？你也可以想象的是，一段程序在解释器中运行时可能会被编译多次，因为每次运行到这段程序时，都会重新编译一次，这样的开销是很大的。

所以诞生了Java，C#这样的预编译语言：


在运行之前，需要手动把源代码编译成中间代码（Java里叫字节码），然后在解释器中执行。
这种架构避免了上面纯解释器中编译源代码的开销，所以相对会有效率一些。

但 是我不能骗你们，其实我画在纯解释器中的Python，Perl，PHP可能都不会是真的纯解释执行的，这样实在是太没有效率。Python在运行时会生 成pyc的二进制临时文件，看起来很像是预编译的结果。只有JavaScript这种真的不会写得太长的语言（Ajax请原谅我）才会采用纯解释的运行方 式。