编译器语法太严格

⑴ 编译器的工作原理

编译 是从源代码（通常为高级语言）到能直接被计算机或虚拟机执行的目标代码（通常为低级语言或机器语言）的翻译过程。然而，也存在从低级语言到高级语言的编译器，这类编译器中用来从由高级语言生成的低级语言代码重新生成高级语言代码的又被叫做反编译器。也有从一种高级语言生成另一种高级语言的编译器，或者生成一种需要进一步处理的的中间代码的编译器（又叫级联）。
典型的编译器输出是由包含入口点的名字和地址， 以及外部调用（到不在这个目标文件中的函数调用）的机器代码所组成的目标文件。一组目标文件，不必是同一编译器产生，但使用的编译器必需采用同样的输出格式，可以链接在一起并生成可以由用户直接执行的EXE,
所以我们电脑上的文件都是经过编译后的文件。

⑵ C语言的编译器为什么有许多不同的版本并且在不同的编译器版本下C语言的语法规则也不尽相同

C的标准本来就有多个版本,目前编译器采用的标准比较常见的是ANSI C和C99。另外语言标准中也存在未定义行为,留给编译器实现自己去定义。各种编译器对标准的实现也未必完全遵守(C还好,C++这种特别复杂的语言就很难做到完全遵守标准了),而且往往还增加一些自己的扩展,预定义宏之类的。这些都给跨编译器编码带来麻烦。不过总体而言C是个比较单纯的语言,除非程序员故意,一般搞不出太多给编译器出难题的花样。作为长期用C++的程序员,非常羡慕C代码编译时那种飞快的速度。
麻烦采纳，谢谢!

⑶ 为什么编译器需要复杂的语法

新的版本都是基于旧的版本升级过来的，以此来改善编译器的性能、增加对新平台的支持以及提高竞争能力。不同的编译器支持的标准语法是一致的(不然没资格称C编译器)，但是每个编译器自身可以添加额外的语法、库来扩展语言的表达能力，这就是所谓的xx编译器扩展。使用语言扩展通常能获得较高的性能和灵活性，但是损失了跨平台性。不仅仅是编译器有很多版本，语言本身都有很多版本，目前C语言的版本是C11，下一个版本为C1y。

⑷ 请问编程语法规则，是不是根据不同编译器来定的

不，一个语言的语法是早就确定好的，它有一个统一标准——例如 ANSI C。
不同编译器可能有些许不同，比如有的编译器a=b=c结果很可能不一样（所以我们很少这么用
但是大体上，一个语言的编译器得出的结果是一样的，是根据语法规则做出编译器而非编译器确定语法规则。
zhengshu a=0，编译器肯定不认，理由是没有这个type；但是你可以通过typedef自定义任意的类型。

int是一种type，而type varlist;是声明变量的语法（int a; char b;）

你写了int a=0;那么这时编译器做的就是在内存中开出一个能存int数据的空间，然后把0给填进去，再记录下这块内存的地址，并记住这个地址叫做a。至于分析代码什么的，就是编译器的事情了。

——以上。

⑸ c程序在书写时有严格的缩进要求否则不能编译通过

所有的C语言编译器是没有这样的规定的。C语言本身是一种非常灵活的编程语言，包括它的书写格式和语法表达。C语言每一个语句都是以“；”结束，只要遵循这个原则即可，并没有强制要求必须以缩进方式编写程序，也不影响程序的编译。通常以缩进方式编写程序是一种比较提倡的好的习惯和做法，有利于对程序的理解和检查。

⑹ linux下编译tslib，configure之前都正常，但make后就出现错误啦，求解。。

gcc 新版本编译器对语法检查严格，在源文件 ./tests/ts_calibrate.c 中

// 源文件
// if ((calfile = getenv("TSLIB_CALIBFILE")) != NULL) {
// cal_fd = open (calfile, O_CREAT | O_RDWR);
// } else {
// cal_fd = open ("/etc/pointercal", O_CREAT | O_RDWR);
// }
// 需要更改成如下形式
if ((calfile = getenv("TSLIB_CALIBFILE")) != NULL) {
cal_fd = open (calfile, O_CREAT | O_RDWR, 0777);
} else {
cal_fd = open ("/etc/pointercal", O_CREAT | O_RDWR, 0777);
}保存后重新编译即可

⑺ delphi编译器效率高到底是指什么

所谓delphi编译器效率高，一般指的是以下三方面：

1、编译连接时间短，这一点是其他任何编译器都无法相比的（一般来说，VC, VB编译过程所用的时间是Delphi的几倍），原因很简单：Pascal语法限制严格，用户必须规范地编码，省去了编译器的很多麻烦。

2、编译出的程序执行速度快，产生的代码长度短。这一点比VB强，但和VC基本一样，谁也没有优势。不过很多人有误解，以为Delphi类库庞大复杂，加一个控件就要把整个一个源文件全部加进来，代码长度太大，效率太差。其实真实情况是，拥有众多VCL控件类库，是Delphi的一个独特之处，VC的MFC库无法与之相比——MFC有的底层简单封装的类，VCL库都有，但VCL有的上层组件，MFC却根本没有。使用VCL上层应用控件后，代码长度的确比VC大，不过VC却没有这方面的选择，而VC所用的从底层一砖一瓦地编码的方式，Delphi完全支持，而且绝对没任何劣势，代码长度也不长（VC的语法复杂，按C程序员一般习惯做的话，代码长的反而会是VC）。产生误解的原因，是多数Delphi程序员是应用级的，而VC程序员是底层些的，应用程序员大多不太懂得底层代码的编写，只会搬控件、响应事件，以为底层的东西Delphi做不来。

3、对应用级的程序开发周期短——这也就是Borland一贯吹捧的“快速开发工具”的含义。正因为VCL的存在（封装了很多界面组件以及通讯、数据库、internet应用等很多后台功能），对高层应用不再需要一砖一瓦地受累，使开发周期缩短了很多倍。

单纯从技术角度说，编译器效率应该指编译出的代码是否短小/运行速度是否快，以及是否能用较少的源代码高效地实现复杂功能。前一方面Delphi并不比VC差，而比VB强，但并非一骑绝尘；后一方面则的确有一骑绝尘之象。

Delphi的致命缺点，其实不是技术——技术它是领先的，毫无疑问，问题是市场策略和公司实力（Borland只是家小公司），微软“携操作系统以令诸侯”，误导了众多软件开发公司，让它们以为微软的才正宗和好用，造成了事实上的VB，VC用户群远比Borland的庞大，源代码数量也一样是C/C++远远占优，而Borland的C++ Builder却开发得太晚难以形成市场优势。

概括来说，如果你要开发上层应用为主的程序，特别是数据库方面的程序，那么Delphi能让你省不少时间；而若开发底层些的软件，为能有更多相关代码可以参考利用，为能容易地招聘到更合适的程序员，以及为了代码维护方便，都适合用C/C++去做，当然，C++ Builder从技术上说是个不错的选择，只是用户群还太小。

⑻ 为什么proteus8.6自带的编译器只能写2k的程序,怎么样可以设置大一点

proteus自带编译器不太好用，语法比较严格。最好的还是安装使用keil编译器，是标准的C语言语法，且没有2K限制。

⑼ 编译器错误●怎么办

这是两个截然不同的概念。不是叫做：编译器错误，而是应该叫做：编译错误。如果说真的是编译器内部本身（例如：C语言编译器、或者是别的各种编程语言的编译器）出现了bug 的话，那么任何人也没有办法。只有开发编译器软件的软件开发人员才能够解决这样的问题；
如果是在你的源程序中产生的各种编译错误（例如：语法错误、语义错误等），那么你只能够仔细地检查、编译、调试你的源程序了。

⑽ C语言的特点有哪些

1. C语言是一个有结构化程序设计、具有变量作用域以及递归功能的过程式语言。

2. C语言传递参数均是以值传递，另外也可以传递指针。

3. 不同的变量类型可以用结构体组合在一起。

4. 只有32个保留字，使变量、函数命名有更多弹性。

5. 部份的变量类型可以转换，例如整型和字符型变量。

6. 通过指针，C语言可以容易的对存储器进行低级控制。

7. 预编译处理让C语言的编译更具有弹性。

(10)编译器语法太严格扩展阅读：

C语言是一门面向过程的计算机编程语言，与C++，Java等面向对象的编程语言有所不同。其编译器主要有Clang、GCC、WIN-TC、SUBLIME、MSVC、Turbo C等。