Vczh Library++ 3.0终于开始正式进行优化的工作了。当然这里的优化指的是不更改抽象语法树的情况下尽量进行更加好的代码生成。根据经验这一个部分对于程序的影响最为突出。因为一个程序员可能因为具备了编译器的一些知识而写出更加高效的代码，但是却控制不了如何将一个具体的表达式转换成汇编指令的过程。因此这部分不得不尽我所能做到最好。

    目前的进度是将表达式的代码生成分为以下几大类：
    1、计算引用地址
    2、计算引用地址的同时不运行副作用
    3、计算结果
    4、仅运行副作用
    5、将结果保存至某某地址

    除了一些非左值的表达式不具备1和2，或者一些特别复杂的左值表达式不具备2以外，每一种表达是都具有以上5种代码生成算法。这样可以尽可能将无效代码降至最少。举个例子，假设我们为表达式e生成了一串指令is，那么语句s：e;的指令显然应该是is + {pop typeof(e)}。有可能e其实是++i;，那么按照这个方法生成的代码就会有无效代码：
    push addressof(i)
    read int
    push 1
    add
    duplicate-stack-top-item int
    push addressof(i)
    write
    pop int
    我们知道红色的那些指令是不需要的。因为在编译s的时候，我们并不需要知道++i之后的结果，仅仅是想执行这个表达式的副作用。根据类似的思路，于是就有了上面的5大分类。当然每一个分类还会有自己细微的部分。如何让代码生成模块易于维护就成为一个挑战了。代码越复杂，测试也就越复杂。现在只能通过编写足够多的测试用例来尽可能覆盖更多的代码来使代码更加稳定。在修改算法的过程中还会引入新的分支，所以测试用例并不能够总是及时的跟进。于是就有了下面这个设想。

    测试用例总是要人写的，在面对编译器这么复杂的东西的时候，还没什么有效的方法可以来自动生成测试用例。因为我们需要把代码以及生成的指令集都log到一个文件里面，这样当一个用例发生了错误的时候，我们可以更加迅速地知道究竟是哪里出了问题。但是编写测试用例的时候，为了不让语法分析部分的错误导致代码生成的测试结果出错，因此只好在调用代码生成的同时不去运行语法分析的代码。于是我们需要一个将语法树转换成字符串的过程，然后将每一个语句的字符串（可以控制一个基本语句只占用一行代码）变成注释添加到汇编指令的log部分。这样我们就可以轻松知道哪些代码是属于哪个语句的。

    目前这个部分正在开发，但已经距离胜利不远了。当这个部分完成之后，就可以添加很多新的测试用例来测试被分成5类的算法了。目前的测试用例仅能保证每一种表达式都被运行过一次，但是不能保证每一个表达式的每一个代码生成算法都被执行过。

    详尽的测试可以在早期发现最大量的bug，这样可以在后续的语言种类继续建立起来的时候可以专注于该语言种类自己的测试，而不让其基层的错误让测试变得更加麻烦。