本來每年都要寫一篇年經帖來提高一下知名度的，但是最近因為做GacUI太興奮，竟然把這件事情給忘了，實在是罪過。

如果要說我2012年做過的什么事情最重要，那當然要屬開發了GacUI（Home Page, Codeplex, Github）和創建了粉絲群（啊哈哈）了吧。博客到現在還有三個坑沒填完，分別是那個已經坑了好久、大家都要看、但是我卻不知道要寫什么的《C++使用技巧》，還有兩個大家不怎么想看的《可配置語法分析器開發紀事》和《GacUI與設計模式》。

關于GacUI，我已經在微博上做了許多廣告，也有一些人開始嘗試使用它了。目前GacUI還處于一個湊合著能用的beta狀態，我在接下來的很長一段時間內應該會繼續update它。我的本意是要把WPF那么精妙的設計給山寨到C++上面來，從而結束非得用MFC才能正常開發GUI的日子。而且因為之前我用C#的WinForm開發IDE太蛋疼了，parser需要寫兩遍（編譯器一遍，IDE一遍，語言還不一樣），所以我在設計GacUI的時候，質量要求就是朝著Visual Studio看齊的。所以大家會看到我在做GacUI的時候，文本框就內置了高速的著色系統，還做了一個新的parser來產生嚴格的parser或者松散的parser，分別給編譯器和IDE使用。然后我用這個parser寫了一個xml和json的庫，最后在昨天還update了一下Linq to C++，把我看得不順眼的東西都干掉，于是我也擁有了一個Linq to Xml for C++的庫了。

但是GacUI還是有很多東西要做。我腦子里一直有一個清晰的路線圖，而且這個路線圖是直接朝著目標前進的：做一個C++的GUI庫，順便給一個類似Expression Blend那樣子的東西，然后那個框架還可以為我以后開發語言，或者給現有的語言做IDE。所以為了達到這個目標，我至少要給GacUI的控件和對象模型做反射。為了讓大家可以使用，我還得準備一個看起來跟MSDN很像的文檔。因此路線圖就是（粗體的部分已經完成了）

1. 開發控件庫
2. 擁有一套生成Release的工具鏈，包括parser生成器、文檔生成器、各種代碼生成器等
3. 有一個小巧玲瓏簡單好用的XML庫
4. 可以讀PDB把GacUI的對象聲明都拿到手
5. 利用PDB和GacUI的源代碼里面的XML注釋生成文檔
6. 用一個類似C#那樣子的語法來給GacUI“聲明”一個對象模型，讓他可以被反射，也可以用來生成各種語言用的接口，特別是動態語言例如javascript和python的
7. 把PDB的內容和對象模型結合起來，生成C++用的反射代碼
8. 利用反射代碼，設計一個GUI的XML（或者別的什么東西）表示，從而實現動態加載窗口
9. 制作一個長得和操作模式都跟Visual Studio差不多的多文檔編輯框架
10. 用上面的框架開發一個GUI編輯器，用來拖控件生成xml+資源，就可以嵌入C++的exe，或者提供給腳本語言使用了
11. 提供一個腳本語言，作為可選的插件，來簡化復雜GUI的開發
12. 給這個語言提供一個IDE

大家可以看到，這就是為什么我最近要花時間做著色、parser生成器、用parser生成器來生成xml和json的庫的parsing部分、做一個linq to C++并且讓xml庫直接支持就像C#的linq to xml一樣。雖然看起來這些東西跟GacUI本身毫無關系，但是實際上為了實現那個復雜又得自動生成不然寫到孩子出來還人肉不完的反射代碼生成，一定要有配套的基礎設施才行。

關于粉絲群，因為我加入的大部分編程區最后都癟了，所以本來我并沒有創建一個群用來交流技術的想法。不過因為某群友說找不到人研究我以前的代碼的一篇回復，我還是創建了這個群。本來群只有100人的，但是有兩個人贊助了一下，瞬間變成了500人群。所以以后不斷的有人進來的時候我就再也不需要踢掉不說話的人了。很快群里就開始熱烈的討論起問題，經常討論的那么十幾二十個人也這么固定下來了。這個群和別的群不一樣的地方在于，所有問傻逼問題和求大作業的全部被我和鸛貍猿們一個不留的干掉了，啊哈哈哈哈。

由于我在cppblog廣告的關系，加入這個群的人大部分還是做C++的，和S1那群做web的平時跟技術有關的話題完全不同，對待某些人生底線問題（譬如說大括號要不要換行等）的態度也是完全不同。當然偶爾有人經不住每天幾千個消息的沖擊退群了，但是群的熱烈程度還是一點也沒有消減。

關于C++實用技巧，由于我自詡是一個做C++基礎類庫的人，對待C++各種奇技淫巧的態度自然也是不一樣的。盡管大家都說C++學起來很難，坑很多，模板根本看不懂，析構函數沒寫程序函數經常要爛掉之類的，不過我的觀點還是很明確的——其實C++有很多難以理解的功能，都是給寫基礎類庫準備的。只要程序員們不要本著“我一定要看懂類庫怎么寫才用”的這種無聊觀點的話，其實壓力并不會那么大。大多數人覺得C++難，但其實難的部分他做項目大概也是用不上的，本質原因還是不夠淡定導致。

說到這里我就想起了以前跟人家討論的，為什么C#用起來就那么舒服呢？很重要的一點其實是，因為選擇少，所以連煩惱都沒有了。反正事情都能完成，但是方法只有一種的話，你永遠都不需要去比較或者糾結說，究竟要用什么樣的方法來實現。而且一個自帶垃圾收集器+泛型+函數式編程+continuation的語言，語法懂得少也可以用，語法懂得多用起來還特別省事，這一點的確比C++要好得多。回想起2002在CSDN那個著名的對垃圾收集器的大討論，ajoo有一點說得很好，有沒有GC，設計出來的架構都大不一樣。想想原因其實也很簡單，語言一旦帶有GC的話，通常都會對內存做出嚴格的控制，因此你想干掉一個對象就只有一種方法——等他去死了（C#的IDisposable跟這個其實沒什么關系）。因此那些C++里面很執著的誰創建誰刪除啊，COM的什么引用計數啊，這些亂七八糟的東西統統就沒有了。你可以不顧一起的創建各種細粒度對象，不斷地創建各種接口，而根本不用擔心這些對象在死的時候你要干些什么，不僅做出來的設計干凈，用起來也省心。

關于可配置語法分析器開發紀事，按照計劃還剩下兩篇，不過因為這兩篇的內容已經不怎么重要，所以最近的時間都用在開發GacUI上面了。等雜事搞完了之后我就補上這部分內容。

關于GacUI與設計模式，這個系列自從寫了兩篇文章之后，盡管GacUI都是我一手寫出來的，但是我發現要整理出那個架構清楚的表達出來，需要花很多的時間。為了保證文章的質量，我干脆就暫時停下來了，一邊推進GacUI的開發進度，一邊 重新整理。雖然我從來都只用VC++來編譯我的代碼，不過GacUI從一開始設計架構上就有考慮跨平臺的問題，而且我也把對Windows.h的依賴也局限在少數的幾個cpp文件里，頭文件則完全是沒有污染的。盡管代碼里面肯定有VC++對標準作出的一點點人性化修改而垃圾GCC故意不支持從而造成代碼不能再GCC上面編譯，不過在計劃上我大概會在今年的下半年開始把代碼修改成讓垃圾GCC也可以編譯GacUI了。

關于2013年，出去開發GacUI和心目中的那個腳本引擎，我在2013年最想點的技能樹就是編譯器的后端知識了。盡管我在09年的時候做過一個傻逼C語言編譯器，盡管也是編譯成機器碼，但是都是用最簡單粗暴的方法來做的。為了以后的腳本引擎，把這件事情做好，掌握編譯器的后端也就變成必要的事情了。不過我在這里還是想說，編譯器的前端知識也是很重要的。經過設計語言的語法的訓練，和對設計類型系統的訓練，不僅可以提高數學知識、提高智商，還可以讓你學習新的語言和類庫變得更快。編程都是舉一反三的，并不是直接的針對他學習才是長遠看來最好的方法。