编译器的合理性

㈠ 程序编译器的体系结构适合使用什么体系结构

计算机体系结构（ComputerArchitecture）是程序员所看到的计算机的属性，即概念性结构与功能特性。按照计算机系统的多级层次结构，不同级程序员所看到的计算机具有不同的属性。
一般来说，低级机器的属性对于高层机器程序员基本是透明的，通常所说的计算机体系结构主要指机器语言级机器的系统结构。
经典的关于“计算机体系结构（computerarchitecture）”的定义是1964年C.M.Amdahl在介绍IBM360系统时提出的，其具体描述为“计算机体系结构是程序员所看到的计算机的属性，即概念性结构与功能特性” 。

㈡ 计算机有解释器为什么还要有编译器 明显是编译器要快捷于解释器啊…………

下面这个回答可以参考：

编译器是把源程序的每一条语句都编译成机器语言,并保存成二进制文件,这样运行时计算机可以直接以机器语言来运行此程序,速度很快;
而解释器则是只在执行程序时,才一条一条的解释成机器语言给计算机来执行,所以运行速度是不如编译后的程序运行的快的.
这是因为计算机不能直接认识并执行我们写的语句,它只能认识机器语言(是二进制的形式)

编译是将源程序翻译成可执行的目标代码，翻译与执行是分开的；而解释是对源程序的翻译与执行一次性完成，不生成可存储的目标代码。这只是表象，二者背后的最大区别是：对解释执行而言，程序运行时的控制权在解释器而不在用户程序；对编译执行而言，运行时的控制权在用户程序。

解释具有良好的动态特性和可移植性，比如在解释执行时可以动态改变变量的类型、对程序进行修改以及在程序中插入良好的调试诊断信息等，而将解释器移植到不同的系统上，则程序不用改动就可以在移植了解释器的系统上运行。同时解释器也有很大的缺点，比如执行效率低，占用空间大，因为不仅要给用户程序分配空间，解释器本身也占用了宝贵的系统资源。

㈢ c语言编译器的选择

关于C语言编译器的选择(Tc2.0,Tc3.0,Vc6.0等)
我们在学习C语言时通常会面临C语言编译器的选择，事实上C语言编译器可以分为C和C++两大类，其中C++是C的超集，均向下支持C。主要的C语言编译器及特点分别如下:
(1)TC 2.0DOS平台软件。最经典的C语言编译器，系统体积小，简单易学，容易上手，而且很多前人或书籍的程序均基于该编译器，是学习C语言的首选。不过它不支持鼠标，但读者如果掌握几个快捷键，操作时对鼠标可能就不怎么需要了，如：F2 存盘 F3 打开程序 Alt+F3在最近打开的文件之间切换 Alt+F5观察运行结果F9 编译制作EXE Ctrl+F9编译并运行Ctrl+Y 删除当前行 Ctrl+KB定义块首 Ctrl+KK 定义块尾 Ctrl+KC复制块 Ctrl+KY删除块Ctrl+KV 移动块
(2)Tc3.0DOS平台软件。目前比较不错的C/C++语言编译器，支持鼠标，语法着色，多文档，错误跟踪也很好，操作与TC2.0有很多类似，TC2.0会用那么TC3.0也很快会用，缺点是以前很多代码是用TC2.0设计的，而由于TC3.0语法要求的严格性，如要求函数必须定义类型，所以向下存在一定的兼容性问题，所以对于初学者选择起来很矛盾，建议先学会使用TC2.0,而把TC3.0作为能力的补充和平时工具之用。目前有的教材已经选用该编译器，不过需要一个较长的调整期，因为很多源代码需要过渡过来才行，虽然性能上比TC2.0有所提高，但对于初学者没有质的变化，选择时需要注意。
(3)VC++ 6.0Windows平台。目前主流的C/C++语言编译器,包含强大的类和内嵌WinAPI的MFC,具有可视化的编程界面。对于TC等的作品也具有向下兼容的特点，建议读者选用作为C语言过渡到Windows平台编程的首选工具。当然，作为学习，该系统显得有点庞大，不过通过入门的学习，调试旧的Tc程序也可以。还有其他的编译器，例如Win tc、gcc、lcc、BC 3.1等等,事实上，编译器的选择不是最重要的，他们都可以完成基本的C语言编译，不过面向考试的时候，还是根据考试的要求，因为编译器的编译结果存在着一定的差别，特别在一些复杂语法的语句编译上。从目前的形势看，对于从未学习过计算机程序设计的读者来说，学习C语言时，建议开始选择Tc2.0,虽然不能使用鼠标，但几个快捷键的熟练运用基本上可以解决操作的问题，当然有时间的时候了解使用TC3.0就更好了；对于学习过TC2.0的读者来说，平时完全可以在TC3.0或VC 6.0下调试程序，但考试的时候如果要求必须在TC2.0下，那最好上机练习时在TC2.0下。当然，使用如记事本等文本编辑器编辑程序，然后用TC来调试也不失为一种好方法。另外，DOS平台的Tc2.0或Tc3.0都存在某些机器运行时键盘响应迟缓或停顿的问题，Tc3.0可能这种现象要多一点，这主要是由DOS基本内存的不足造成的。可以安装水平考试课题组提供的DOS模拟器来解决问题，该模拟器重新划分更多的内存，效果不错。
新的类似软件平台也需要读者关注，那就是java和Viusal C#,因为从发展的眼光来看，目前软件设计平台有一定的趋同趋势。例如：java和C#，都来自于C和C++,都作了不错的扩展和优化。对于深入学习C语言的同学，未来几年请务必学习VisualStudio.Net或者Java,因为这二者代表了现在的软件设计主流。他们的主要特点是：优秀的IDE设计环境，强大的WEB服务设计功能，对C++的优化和扩充，基于虚拟机的运行模式，优秀的面向系统开发，可视化的较为成熟的面向对象的程序设计机制等等.

㈣ 编译器具体实现中比较巧妙的思想有哪些

这种做法的好处是：
可以作为解释器性能升级的一个简单路径，写解释器的代码而得到初级编译器的性能。事实上JamVM的解释器可以配置为多种实现方式：switch-threading、indirect-threading、direct-threading、inline-threading，它们的差别仅在于对opcode的dispatch方式不同；所有实现方式都共享同一份handler代码。
这种做法的缺点是：
这样写得到的“编译器”无论从代码组织还是程序思路都还是解释器的那套，从编译器的角度看很别扭。它最终实现出来效果跟从编译器角度出发的template-based JIT一样，但我觉得后者的思路更直观，代码也通常更清晰一些。
这种做法仍然无法跨越字节码边界做任何优化，因为每个opcode对应一个单独的handler，而这种做法的代码生成仅仅是把handler拷贝到一起而已。
要在它的基础之上进一步提高性能可以直接对字节码序列做些简单模式匹配，以便跨越字节码边界做优化。但这样做通常是自讨苦吃，工程上很难持续下去。

㈤ 编译器本身是如何进行测试的

编译器最重要的性质就是保证语义的正确。比如，从高级语言翻译到机器指令之后，指令必须正确的表达原来程序的意思。所以一般编译器测试都包含一些源程序，用来覆盖可能出现的各种情况。基本的原则是：原来程序的结果 = 编译后机器指令运行的结果。机器指令运行的结果很容易知道，运行一下就知道了。可是原来程序的结果你怎么知道呢？
为了解决这个“原来程序语义”的问题，最好是写一个解释器，准确无误的表达原来的代码的语义。所以我们的要求就是：
高级语言解释器（源程序） = 机器执行（机器代码）
由于处理器其实就是一个用来执行机器代码的解释器，这里有一个很美好的对称关系：
interp1(L1) = interp2(L2)
另外还有一个问题，就是编译器一般需要经过多个转化步骤（叫做 pass）才能最后编译为机器指令。比如，
L2 = pass1(source)
L3 = pass2(L2)
L4 = pass3(L3)
Ln = passN(Ln-1)
machine_code = codegen(Ln)
由于源程序经过了很多步骤猜得到最后的机器指令，如果你使用上面的公式，就会出现以下一些情况：
1. 知道结果错了，但是却不知道到底是哪一个 pass 错了。
2. 结果没有错，但是中间却有 pass 实际上是错的。但是由于之前的 pass 把输入程序的一些结构给“优化”掉了，所以错的那个 pass 其实没能得到触发错误的那个数据结构。所以测试没能发现错误。如果以后前面的那个 pass 被修改，错误就会暴露出来。这是非常难以发现的潜伏的危险。
为了防止这些情况出现，一些编译器（比如 Chez Scheme 和 Kent Dybvig 的课程编译器）使用了对每一个 pass 进行测试的做法。具体的方法就是为每一个中间语言都写一个解释器，把这语言的语义完全的表示出来。这样我们就需要检查一组等式：
L2 = pass1(source)
高级语言编译器（源程序） = interp2(L2) // 测试 pass1 的正确性
L3 = pass2(L2)
interp2(L2) = interp3(L3) // 测试 pass2 的正确性
这样一来我们就能独立的判断每一个 pass 的正确性了。
这些是基本的语义测试原理。另外除了语义，可能还有一些“表面”一些的测试，它们看代码本身，而不只看它的语义。比如尾递归优化的测试应该确保输出程序的尾递归得到正确的处理，等等。这些是语义测试检查不到的，因为尾递归没有正确处理的程序大部分也能输出正确的结果。
普通的单元测试方法也可以用来测试一些编译器里的辅助函数，但那些不是编译器特有的，所以就不讲了。
另外，就像所有测试的局限性一样，你没法枚举所有可能出现的输入，所以以上的测试方法其实也不能保证编译器的完全正确。

㈥ 编译器的组成及各部分的功能及作用

1. 词法分析 词法分析器根据词法规则识别出源程序中的各个记号（token），每个记号代表一类单词（lexeme）。源程序中常见的记号可以归为几大类：关键字、标识符、字面量和特殊符号。词法分析器的输入是源程序，输出是识别的记号流。词法分析器的任务是把源文件的字符流转换成记号流。本质上它查看连续的字符然后把它们识别为“单词”。 2. 语法分析 语法分析器根据语法规则识别出记号流中的结构（短语、句子），并构造一棵能够正确反映该结构的语法树。 3. 语义分析 语义分析器根据语义规则对语法树中的语法单元进行静态语义检查，如果类型检查和转换等，其目的在于保证语法正确的结构在语义上也是合法的。 4. 中间代码生成 中间代码生成器根据语义分析器的输出生成中间代码。中间代码可以有若干种形式，它们的共同特征是与具体机器无关。最常用的一种中间代码是三地址码，它的一种实现方式是四元式。三地址码的优点是便于阅读、便于优化。 5. 中间代码优化 优化是编译器的一个重要组成部分，由于编译器将源程序翻译成中间代码的工作是机械的、按固定模式进行的，因此，生成的中间代码往往在时间和空间上有很大浪费。当需要生成高效目标代码时，就必须进行优化。 6. 目标代码生成 目标代码生成是编译器的最后一个阶段。在生成目标代码时要考虑以下几个问题：计算机的系统结构、指令系统、寄存器的分配以及内存的组织等。编译器生成的目标程序代码可以有多种形式：汇编语言、可重定位二进制代码、内存形式。 7 符号表管理 符号表的作用是记录源程序中符号的必要信息，并加以合理组织，从而在编译器的各个阶段能对它们进行快速、准确的查找和操作。符号表中的某些内容甚至要保留到程序的运行阶段。 8 出错处理用户编写的源程序中往往会有一些错误，可分为静态错误和动态错误两类。所谓动态错误，是指源程序中的逻辑错误，它们发生在程序运行的时候，也被称作动态语义错误，如变量取值为零时作为除数，数组元素引用时下标出界等。静态错误又可分为语法错误和静态语义错误。语法错误是指有关语言结构上的错误，如单词拼写错、表达式中缺少操作数、begin和end不匹配等。静态语义错误是指分析源程序时可以发现的语言意义上的错误，如加法的两个操作数中一个是整型变量名，而另一个是数组名等。

㈦ c++各种编译器有什么不同，应该不存在哪种编译器最好的说法吧是不是只要学会用一种编译器就可以了

每种编辑器适用环境都是不一样的。对于初学者来说 如果你想学习linux gcc是一个非常不错的编辑器。。又是开源的。。其他的要依你的编程环境来确定。。标准C的程序编辑器基本都支持的。所以简单的程序选择哪一种都差不多，但是如果用到专业的函数 比如itoa 这就是windos 特有的函数了 也就是说只有VC支持

㈧ sizeof(a)++编译通过,++sizeof(a)报告缺少合法的左值

关键是要把sizeof(a)++理解为：sizeof((a)++)，详情请看后面的分析。

1.要理解sizeof运算符的语法，其实sizeof后面可以直接跟表达式的，
如：sizeof a; // 与sizeof(a);等价
sizeof a+1； // 与sizeof(a+1);等价

2.要理解sizeof后面的表达式到底会不会被编译程序编译，并进行真正的计算
其实编译器只想知道sizeof 后面的表达式的类型（进而知道所占存储空间），但是并不会真正的计算后面的表达式。
如：sizeof b=3+1; // 假设b原来为0，则编译这条语句以后b仍会为0

下面我们分析一下sizeof(a)++; //合法,编译通过
根据第一条，我们应这样理解该表达式：sizeof((a)++);即sizeof运算符求的是后面整个表达式((a)++)的类型；
而不能理解为:(sizeof(a))++;，否则4++;也可以通过编译。
那么既然把((a)++)看作了整体，为什么a的值不会加1，可根据第二条解释：由于整个表达式作为sizeof的参数，所以表达式((a)++)的值根本没有计算。

对于++sizeof(a);显然不能通过编译，这里就不解释了。

下面我们用一个例子说明以上分析的合理性：

#include<stdio.h>
int main(int arg,char **argc)
{
int a=0,b=0;
sizeof a; // 说明sizeof对于简单的表达式可以后面不用括号，佐证论点1

sizeof (b=3+1); // 说明sizeof里面的表达式并不会计算，佐证论点2
printf("b=%d\n",b);
return 0;
}

程序的输出结果为：b=0
这说明了sizeof里面的表达式并不计算，因此楼主的sizeof(a)++;中a的值不变是可以理解的。

㈨ 如何更改c++编译器设置。

你好，我刚开始也不习惯这个末尾要加空格的警告，因为最初学习用vc6时没有这个要求。后来渐渐习惯了，再说这个在末尾加一行空格还可以提醒你检查下末尾是否完整，挺好的呀。我感觉你没有必要非要把这个警告去掉，现在好多编译器都有这个警告，这个设计也有其合理性。
谢谢，望采纳。