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大分類。當然每一個分類還會有自己細微的部分。如何讓代碼生成模塊易于維護就成為一個挑戰了。代碼越復雜，測試也就越復雜?，F在只能通過編寫足夠多的測試用例來盡可能覆蓋更多的代碼來使代碼更加穩定。在修改算法的過程中還會引入新的分支，所以測試用例并不能夠總是及時的跟進。于是就有了下面這個設想。

    測試用例總是要人寫的，在面對編譯器這么復雜的東西的時候，還沒什么有效的方法可以來自動生成測試用例。因為我們需要把代碼以及生成的指令集都log到一個文件里面，這樣當一個用例發生了錯誤的時候，我們可以更加迅速地知道究竟是哪里出了問題。但是編寫測試用例的時候，為了不讓語法分析部分的錯誤導致代碼生成的測試結果出錯，因此只好在調用代碼生成的同時不去運行語法分析的代碼。于是我們需要一個將語法樹轉換成字符串的過程，然后將每一個語句的字符串（可以控制一個基本語句只占用一行代碼）變成注釋添加到匯編指令的log部分。這樣我們就可以輕松知道哪些代碼是屬于哪個語句的。

    目前這個部分正在開發，但已經距離勝利不遠了。當這個部分完成之后，就可以添加很多新的測試用例來測試被分成5類的算法了。目前的測試用例僅能保證每一種表達式都被運行過一次，但是不能保證每一個表達式的每一個代碼生成算法都被執行過。

    詳盡的測試可以在早期發現最大量的bug，這樣可以在后續的語言種類繼續建立起來的時候可以專注于該語言種類自己的測試，而不讓其基層的錯誤讓測試變得更加麻煩。