再一次亲密接触

这个学期的编译原理课程实验，我要实现一个小型的编译器，至少要做到翻译中间代码为止，至于语法就简单点行了。由于很多前辈一再强调c语言的重要性，以及编译后的程序如何如何高效地执行。所以在写这个编译器时，我选择了c，因为编译器的执行效率要求还比较高，也顺便巩固巩固c在我的记忆中的地位。

上次写了个自下而上语法分析程序，但是那还是没有进行词法分析的，那里我假设所有的终结符（terminate）都是单字符的，所以词法分析就变成了直接从缓冲区取一个字符。

今天下午终于开始动工构造我的词法分析器了，这可是整个编译器的基础设施，如果词法分析没有实现好，或是执行的很低效（比如：读取源文件时频繁的文件I/O访问）将会直接影响到整个编译器的性能。所以构造词法分析的关键就集中到了怎样减少文件访问次数上，这马上令人联想到了缓冲技术。

在这里我用的是Buff Pairs技术，即用一个Buff分成两半，巧妙地将他们连成环，构建出一个对用户来说好像用不完的Buff来。设计思想很简单：如果当前指针读到了另一半，就先从文件载入到另一半再读。当然里面有几个需要注意的问题，这里就不提了，详情可见龙书（《Compilers: Principles, Techniques, and Tools》）89页。这里我要说的一个问题是，由于要循环访问同一个Buff，这就要求每次访问数组时最后要加一个%BUFF_SIZE以防止访问越界。这个道理很简单，可世上往往有很多事情是道理越简单，结果却越被人忽视了。我就有一个地方忘记加了。结果控制台打印出来的结果可想而知了，出几个正常的结果，突然中间冒出一个乱码，然后继续正常，又乱。一开始我很镇定，肉眼调试，一行一行检查代码，除了越来越发现我的逻辑很严密外没发现任何别的东西：）。最后抗不住了，借助vs端点调试，立马发现一个数组索引超出了BUFF_SIZE了。加上%BUFF_SIZE，立马解决问题。

问题虽然解决了，但心中还是不平静。为什么c没有提供数组越界检查？c#里肯定会抛出异常的，那排错就简单多了。马上又一拍自己脑袋，c拿什么来抛？根本没有异常机制！c的高效就是因为其朴实，原始，没有任何高级功能的修饰，所以这样带来的执行高效就要用开发周期的延长和高水平的程序员来换。

但愿c长久，高手共婵娟！呵呵。