个人认为操作系统的复杂程度没有编译器技术的复杂程度高，我接触过 ucos 等嵌入式操作系统，这些系统在任务调度、内存管理上的基本算法都是比较容易理解和实现的，关键是对硬件平台的理解，对系统架构的设计和代码的优化更加重要。而编译原理不同，其中的形式语言与自动机技术，是极其高深，抽象的理论知识，需要严格的演绎和推导，其理论的晦涩和技术的复杂程度，学过编译原理的人，都应该深有体会。而至于像飞燕这样的语法加亮程序，这样简单的应用，当然可以不借助任何分析工具来完成，这样也可以锻炼自己的编程能力。

顶BockCarry
编译原理是我在大学学习计算机时感受的最牛的计算机科学理论。
若论使用算法的密集度，OS和compiler是不能比的。OS中使用的技术用的算法并不高深，构造一个kernel更像是一个工程，而构造一个compiler更像是一个艺术作品，程序设计的艺术。

楼主的程序只是做了简单的C词法分析，编译理论对词法分析进行了透彻的研究，从正则到DFA构造很简单，从DFA到词法分析程序的编写也没有什么技术含量可言。在这方面的算法研究使得写一个词法分析程序已经程式化了，这种枯燥无味的过程往往借助lex进行自动生成，就想现在的IDE可以自动生成SQL语句一样。

BockCarry能在本科时做一个完整的编译器我很佩服，做到中间代码生成我就没有耐心了，寄存器分配以及后面的生成可执行程序我觉得太枯燥已经做不下去了。

偶换了一个编译模式，现在这个版本应该运行上没有问题了
顺便想了一个办法，把它做得更通用。
我很清楚地知道制作编译器有多么复杂，所以我目前也只做语法高亮

[color=white]

过奖了，我的作品也不过是一个试验品，也并没有最终生成目标代码，生成的结果是四元式形式的中间代码，没有做代码优化，就直接写了一个虚拟机，使其可以直接运行编译生成的四元式。所以说来还是有点惭愧了，其实做的也不是很好，基本上没有什么实用价值。

我以前做了一个解释运行的编译器，类似于JAVA，是半编译半解释的…………不过后来失败了的说，主要是LR文法的构造问题……………………
话说，半编译半解释的编译器还是很好做的，因为没有代码优化和寄存器分配………………

嘿嘿，我和你一样，只不过生成的是不等长的后缀表达式…………

顶起

[color=white]

不过还是觉得vc6的语法高亮看上去最爽。。。

你是说字体还是什么？？

[color=white]

这个不错`~本来我也想做一下~~一直没时间~~