GacUI
本来每年都要写一篇年经帖来提高一下知名度的，但是最近因为做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语言编译器，尽管也是编译成机器码，但是都是用最简单粗暴的方法来做的。为了以后的脚本引擎，把这件事情做好，掌握编译器的后端也就变成必要的事情了。不过我在这里还是想说，编译器的前端知识也是很重要的。经过设计语言的语法的训练，和对设计类型系统的训练，不仅可以提高数学知识、提高智商，还可以让你学习新的语言和类库变得更快。编程都是举一反三的，并不是直接的针对他学习才是长远看来最好的方法。