missdeer之程序的野望

　　我一直在寻找，甚至试图自己编写一个Source Insight的替代品，主要看中它作为一个源代码阅读工具，并具有良好的通用代码编辑功能。如果一定要找出同类产品来，还真是比较难，也许Komodo IDE和SlickEdit在通用代码编辑器的范围上可以往上靠，但在代码阅读器的范围内，实在很少见，可能doxygen和understand for C++可以勉强算是一类，但实现方式差别很大。现在有了DForD SourceCoding，总的说来，它是最接近Source Insight定位的同类产品。
　　DForD SourceCoding具有良好的中文支持，这得益于Scintilla控件的完美实现和ICU的强大兼容性。Source Insight的中文支持一直是其软肋，多年来没有什么实质性的改进，无论是保存项目文件的路径字符，还是文件中的字符，凡是中文，都很有可能出现轻重不一的问题，DForD SourceCoding则完全没有这些问题。
　　DForD SourceCoding使用Tab栏多文档界面，很难想像如今还有一个拥有大量用户的多文档界面的软件，居然没有Tab栏，Source Insight就是那么一个独树一帜的软件，以至于有牛人通过逆向工程等手段，给Source Insight开发了外挂，通过外挂给Source Insight添加Tab浏览等功能，可谓用心良苦。
　　还有一个大问题是DForD SourceCoding的代码编辑器是支持代码折叠的，而Source Insight至今仍无任何迹象显示要在这方面有所改进。代码折叠也算是众多Source Insight用户特别期待的一个功能了，对于现在一个完整的代码编辑器，基本上可算是标准配置，可是比较遗憾的是，这个功能似乎连外挂也是不能指望上了。
　　当然DForD SourceCoding也有不少缺点，比较明显的是，速度比较慢，比起Source Insight不是差了一两个数量级。其次，DForD SourceCoding的代码分析功能相比Source Insight来说，不够精准。DForD SourceCoding直接使用了ctags和cscope来进行代码分析，而Source Insight应该是对cscope进行了一定的改进，而且跟编辑器结合得更紧密。另外，DForD SourceCoding虽然本身是基于一个Lua脚本语言扩展的架构实现，但它并不开放这个扩展构架以便用户进行二次开发，而Source Insight则是向用户开放了脚本扩展的能力。所以说，DForD SourceCoding还需要持续改进，才能彻底战胜Source Insight啊。
　　最后有一点值得说的是，Source Insight比较贵，DForD SourceCoding的定价才是它的一半多一点，当然这要看用户如何选择了，是否少花近100美元买80%功能的呢？

　　昨天算是发布出去了，这次花了3个月时间。修正了一些bug，添加了一些新特性，修改了一些功能。总之，现在回头看来，不那么令人满意。
　　没有UT是最大的问题，根本不能保证某次修改会影响到什么。这不能再忽视了，test case要开始补起来。
　　其次是编译器差异和编译模式差异之大，出乎我的意料。好几次都是VC编译出来的正常，用GCC编译的就不正常。或者debug编译的正常，release的不正常。这是因为我离不开Visual Assist，也有点离不开VC的调试器。这点实在不好解决。
　　再次是Lua开发环境还是不够好用。Auto Completion不准确就不说了，有时Auto Completion出来过后，整个程序就会很卡，不知道为什么。以后要能做到Auto Completion分库，可以让用户随意通过增删文件来增删符号库。
　　最后一点是对架构的不满意。经过如今大半年的迭代发现，插件扩展架构的可扩展性和可裁剪性不够灵活。这点现在还没有具体的思路，或者说一直觉得实现上也许有点麻烦。
　　除了这些外，还有许多特性要增加，比如增加几种常见的SCM工具支持，开放二次开发接口，增加插件扩展的开发环境等等。

　　这是个很简单的功能，但却很有用。SciTE和Notepad++都有一套自己的实现，感觉Notepad++的效果比较好。从它们的配置文件中提取出众多编程语言的注释符号即可。注释分为两类，一类是行注释，另一类块注释。不是每种编程语言都支持这两类注释方式，甚至有的编程语言都不支持可以有注释。当然这个不是很重要，反正所有的信息可以写在配置文件中。
　　昨天还意外地发现，用boost.lambda对std::basic_string和wxString对象进行==比较时，用VC编译的运行正常，用GCC则一直不正确。一开始还以为是两个编译器对两种字符串对象的内存布局不一样引起不同的结果。最后发现，其实是我自己写的迭代器在std::find/std::find_if中不正常，在GCC编译的程序中，比较谓词根本没有被调用。回想起来当时看到GCC的std::find/std::find_if对于随机迭代器是特化实现的，想想其实我那个迭代器不需要随机迭代器，用双向迭代器就可以了，改了后，一切都正常了！

　　昨天完成了自定义快捷键的特性。该特性在配置对话框中实现与用户交互。
　　首先，在程序启动时，装载所有菜单项时，把所有菜单项的ID、标题、快捷键信息记录下来，作为缺省的配置。将缺省配置保存到文件中，然后查看是否存在保存了修改后配置的文件，如果存在该文件，则装载该文件的配置，应用到程序中。应用过程分两步，刷新菜单显示和设置快捷键表。
　　接着，处理在配置对话框中的用户交互响应。在对话框初始化时，加载当前正在使用的快捷键配置。用户可以修改其中任意一项的配置，当用户选择应用修改后的配置时，就将当前配置保存到文件中，以便下次程序启动时可以装载这个修改后的配置。
　　基本处理流程就是这样。用wxWidgets实现时，也是比较容易的。wxWidgets提供了快捷键相关的几个类和方法，相当方便，包括wxAcceleratorEntry、wxAcceleratorTable、SetAcceleratorTable等等。
　　这里不得不抱怨一下，wxWidgets对于一些明明日常需要使用的类和方法，竟然没有文档进行说明。另外还发现个问题，wxAcceleratorEntry有个ToString方法，当其中的Key Code是除了字母、数字外的其他的可打印字符时，会断言失败，太Orz了，只好自己写代码转换了。

　　Relation视图可以算是完成了，至少是处于可用的状态了。基本原理就是调用cscope这个程序，本来这个程序是开源的，而且是用BSD许可的，比较干净的做法是把代码拿来编译进自己的工程里。不过我懒得研究那个代码怎么编译了，直接调用现成的可执行程序，通过管道获取其输出，然后自己解析一遍输出内容，显示在relation视图上。这样看来这该是个很容易实现的功能，但是实际上我却花了不少时间。原因是我一开始考虑得过于简单，把所有工作都放在一个singleton中完成。既要生成新进程，又要获取管道输出，同时还要兼顾老进程没有结果又有新进程的请求到来。于是总是在同时有多个进程时崩溃。后来把新老进程调试和获取管道输出分别放在两个类中实现，就都好了。
　　另外还有个问题是用gcc编译。现在这个版本基本上也到了收尾的阶段，我也买了个Mac Mini，希望能把它移植到Mac OS X上。Mac OS X上可以用gcc，于是我就先尝试在Windows XP上用gcc编译这个工程。这些天一直在折腾这事，总是由于这样那样的原因失败。到今天为止，终于可算是正常通过了，有几点需要记一下。我一直用boost svn trunk中的代码，绝大多数时候，用VC编译链接都是没问题的，可是这次用MinGW中的gcc 4.4.0把boost.thread链接到工程中时，仍然会报有几个符号找不到，如果是用正式发布的1.43.0版本的Boost，是可以正常链接通过的。gcc不支持在函数体内定义结构体（类），VC9是可以的。gcc在用boost.lambda时有些情况会编译不通过，就是几个结构体内的成员被lambda bind后再进行比较的情况，但是VC9是能编译通过的，而且也不是所有这种bind并比较都不能编译过，具体的还得继续研究一下。总的说来，gcc对类型检测比较严格，呃，说难听点，是比较死板，不如VC那么智能。还有种情况是gcc编译wxString::Format时，如果第二个参数开始传入的是wxString，运行时会出错，但它又报不上来，基本上就是直接崩溃，VC在这方面又做得好得多，不过这点我估计是受不同编译器对对象内存布局不同引起的，所以也许gcc真是无能为力，VC那样可以用算是歪打正着吧。
　　好吧，总之最头痛的两件事算是解决了。