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

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

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

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

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

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

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

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

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

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

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

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

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