All Stories
今天疯丫头发邮件来，随便聊起各自的近况。这个性格柔弱却有点儿自己的小固执的姑娘，看着就是那种让人忍不住想欺负一下，却又忍不住要好好疼惜的人。想起以前一起玩耍的日子，还有她对我的各种大决定的意见，有时候让我觉得有点儿困惑。 也许我在她眼中真的就是一个小弟弟，偶尔在她的面前会表现出一些小孩子脾气来，也许有时候我在她眼中又是一个男人，站在女人对面的男人，希望能做些理应不该由女人担当的事情。 原本被我深深压抑在内心底层的那些亘古遥远的回忆和情绪，又都活络起来。也许唯有时间可以化解这一切。
书在桌上摊开好几天了，不过一直没有投入进去用心读。今天似乎也有点闲了，于是认真地看了一会儿。这本书在去年《软件调试》上市做宣传的时候就已经听说了，还花了点时间去网上找过英文的电子版本，尽管后来发现公司网上很早前就有人发过了。找来英文电子版也就纯粹是满足一下心里那种奇怪的怪癖吧，而从来没有开始看过。 今天读来，发现《Windows高级调试》和《软件调试》基本上两本没有交集的著作，但在一定程度上却是互补的。《软件调试》着重的是原理和底层设施的介绍，而《Windows高级调试》则注重实践，应用各种现有的软件工具，调试各种软件问题。由此联想到另外一本书《Windows用户态程序高效排错》，该书则是案例形式，内容显得比较零碎，不如《Windows高级调试》那么系统化。 最近几个月来，在负责项目组内的core dump文件分析工作，由此才对该领域开始重视。一直以来，都是依靠WinDbg的!analyze -v命令进行分析，如果它能打印出最后的调用栈，而且调用栈又能比较明显地指出出错的源代码行，我才能连猜带蒙地得出一个定位结果并以此指导问题修改。但这样的好事并不多，大概还有3层左右的core dump直接靠!analyze -v是得不到那么明显的信息的，于是对这方面的技能要求就高了。 今天又从一个同事那里得到一个ppt，里面是公司一个传说中的core dump分析组的演示，原来还怀着比较崇敬的心理希望能从中学到那么一招半式的，结果从头到尾翻了一遍后，发现他们就是直接调试的debug building，让我比较失望，同时更是有些不屑，不过如此嘛！ 最终还是得靠自己呀，总之看了《Windows高级调试》一书中对于“栈”的调试那部分后，我隐约觉得，在这书的指导下，加上这么多的实践机会，应该能让我在分析core dump的能力得到很大的提高。
前些天鬼使神差地换上了MinGW官方的4.4.0Release，当时也没怎么想什么后果，只是觉得这4.4.0无论是在语言上或者库上，都向C++0x靠近了不少，就应该拿来用用。昨天兴起，启动了CruiseControl，却发现其中一个用到了wxWidgets的工程构建不通过，依次修改，修改好几次，才终于搞定。 换编译器是件大事啊，boost要重新编译，wxWidgets要重要编译，这些都是比较正规的使用了C++的库，最近一次出错，是发现我的工程在链接时找不到一些符号，而其中一大批符号的名称中都有sjlj字样，想来是异常处理机制的问题了。上官网看了一下release notes，原来它把默认的异常处理机制从sjlj换成dwarf-2了，而我原来用的TDM-GCC是默认用sjlj的，所以只要全部重新编译工程就可以了。传说中，这个dwarf-2在没有异常时，是0开销的，不过TDM-GCC的网站上说，用dwarf-2前，要先仔细确认一下，该工程会链接到的那些DLL中如果要抛出异常，是用什么机制的，除非能保证它们也都用dwarf-2的方式或者干脆不抛异常，不然还是老实点用sjlj方式的好。不过我想，我在这方面的顾虑很小吧。
无意中在一个讨论组中看到Chrome的新differential算法Courgette（http://dev.chromium.org/developers/design-documents/software-updates-courgette）的讨论，其中提到一个Develper Channel从190.1到190.4的升级例子：完整升级包：10,385,920字节，一般bsdiff算法：704,512字节，而Courgette算法：78,848字节，近十倍的空间效率提升啊！真是太恐怖了，直到今天我才知道，原来对于二进制补丁，也是有这种优化算法的，汗啊！http://neugierig.org/software/chromium/notes/2009/05/courgette.html 这篇文章也对这个算法进行了介绍。大体上，Courgette算法目前是基于x86体系的，适用于exe、dll等可执行文件补丁，它会将这些新旧版本二进制码进行反汇编，在反汇编的基础上进行比较，据说是将二进制文件中所有的internal pointer/reference的地址重新符号化, 然后再计算differential，得到补丁。 另外一个博客中也有一篇讲优化二进制补丁算法的，http://blog.csdn.net/housisong/archive/2006/04/11/658863.aspx。 由此我想到我们现在的自动升级程序，都是完整文件下载替换的，土了啊！
这两天在做一个特性，其中一段很经典的根据不同的类型id来创建不同的对象的代码，想到了《Modern C++ Design》中的那个实现，马上找来Loki用。 非常简洁的代码，定义一个基类，然后就可以根据类型id来创建对象了，如果创建对象的时候需要一些参数，也很容易，另外定义一个Loki::Seq就可以了。 每个派生类可以在源文件中用一个匿名的namespace保护起来进行注册，这样就彻底达到了只要加入该源文件，就有该类，不加入该源文件，就没有该类。不需要修改其它任何代码。 挺好用的！
做IDE，很重要的特性是对代码进行分析，并根据分析后的结果做些其他的事情。 出于好奇，在google上搜索一下python、ruby、lua的相关资料，只要以AST为关键字进行搜索，就能找到一些信息。其中，Lua有好几个第三方的项目，专门或顺带实现了AST操作的功能。Ruby的也是第三方的项目实现的，Impeller就是修改了某个第三方实现。Python则比较强悍了，由官方标准库中提供该功能。 虽然这些脚本语言的核心解释器都是用C实现的，不过这些AST功能的实现一般却是直接用脚本完成了，这也是可以理解的，或多或少地可以利用核心解释器中的一点功能嘛！
本来我一直是觉得VS2008自带的Prefast在这方面的需求足够了，不过似乎老雷对于PCLint有着近乎宗教般的狂热信仰和崇拜，时不时地催促一下。 不过在公司里的项目中，折腾了不少时间，仍然没能正常使用，总是要么只输出一些头文件中的检测信息，要么就索性什么都没有输出。后来同事发现，这似乎是跟我们的代码包含的头文件关系太复杂有关，他从其他项目里随便找个cpp文件来，用PCLint就是很正常地检测了cpp中的问题。 昨天晚上回到家，从网上找到PCLint v8.00x，并从官方网站上找到最新的适用于v8.00的.lnt文件，然后开始PCLint的再次尝试。惊喜地发现，自己写的一个MFC小程序用PCLint确实可以正常输出些内容。但想想公司里的另外一个小项目，也是很简单的头文件包含关系啊，为什么就不能正常使用呢？最终还是没有找到确切的原因，太奇怪了，网上随便搜索了一下，关于PCLint的问题定位方面的资料几乎没有，全是些基本使用说明。 比较了一下，PCLint的速度真是慢得可以，似乎比Prefast慢很多很多。 在试用了PCLint和Prefast后，我发现它们对提高代码质量有客观上的能力和辅助作用，但我觉得人才是最主要的因素，我在短短的试用过程中，突然醒悟，很多时候是纯粹为了通过它们的检测而机械地修改代码，怎么能躲避它们的检查就怎么改，而完全丧失了作为一个有责任心有进取心的开发人员应该具有的致力于编写出优质无错的代码的积极心态，这实在是一件很恐怖的事情。再联想一下，对于衡量代码质量的其他静态指标，比如圈复杂度，重复代码行统计等，也有相同的问题。为了降低某个函数的圈复杂度，就无所不用其极地运用一些诡异手法，只是为了骗过工具的检查，反而降低了代码的可读性可维护性。 程序员啊，真是一个让人头疼的群体。
昨天开始，就有人发现最近的版本不正常，严重不正常，甚至都不能启动！这是个极端致命的问题啊，于是开始有同事着手定位。昨天没有进展，顺延到今天，今天上午也没有进展，下午的时候人都慌了，于是3个人投入进来定位问题。最初只是通过dump文件发现，在启动程序时，会自动加载文件，并通过正则表达式分析该文件，而这正则表达式使用的是boost::regex，可是在创建boost::regex对象时，它的构造函数就崩溃了，没有抛异常。那大量的时间就花在分析为什么构造函数会崩溃上。而且比较诡异的是，Debug版本是没有问题的，只有Release版本才不正常。于是全部人都切换成Release进行编译、定位。直到很后来，另一个同事发现，只要在该程序的任何处使用到boost的东西，就会崩溃！这没法活了！于是我们不约而同地想到，这应该是编译选项引起的问题。从回溯CruiseControl上的编译版本，发现最后一次表现正常的构建之后，有7次提交记录，才构建出下一个版本，范围可以缩小到这7次提交记录中。其中只有一次是我在工程设置中定义了一个预处理宏_SECURE_SCL=0，为了在VS2008的Release模式下编译过1.39.0版本boost::signals2的代码！把这个预处理宏去掉，并暂时注释掉因为没有这个宏而编译不过的boost::signals2应用代码，编译，发现一切又都恢复正常了！ 该死的_SECURE_SCL，看来只能等1.40的boost了！
发现前段时间写的那些代码很不稳定，总是会崩溃！今天被人翻出来批判了一把，惭愧啊！ 问题出在多线程上。一个编辑器对象创建后，会创建一个新的线程来分析编辑器中的内容，然后把分析后的结果保存在成员变量的。这时如果在保存结果之前，编辑器对象已经被销毁了，则访问成员变量也是不可行的，所以我在编辑器对象被销毁的时刻（析构函数中）强行打断线程的执行。 另一个问题，同样是编辑器对象创建后，要创建一个新的线程来分析编辑器的内容，然后根据分析后的结果，来对编辑器做些特定的操作。这里我使用了boost::signals2来进行通知，其实这不是必要的，用boost::function作为回调函数也是可以达到目的的，毕竟在我看来，使用boost::signals2的区别只在于它可以绑定多个接收槽。结果问题来了，boost::signals2的自动对象管理似乎只能依赖于boost::shared_ptr的对象生命期管理，而这boost::shared_ptr的使用在我这种情况下就比较棘手了，原来只是把该对象作为一个聚合对象实现，而似乎boost::shared_ptr的使用最好是从一开始就是在堆上new出一个来，并以boost::shared_ptr的形式保存起来，现在要改，也是有不小的工作量。说实话，在我看来，这样的接口，还不如boost::signals的trackable基类的实现好呢。而且另外还有个问题是，就算这信号-槽的机制真正正确起作用了，信号过来后，仍然是在一个工作线程中对编辑器对象进行一些操作，而这些操作进行到半途，如果编辑器对象突然被销毁了，那也是不行的，所在不得不在这个接收槽的处理过程中也加入线程中断的检测。 这样，貌似理论上两个问题都可以解决了。于是用boost::thread实现吧，它有比较方便的创建新线程的接口，可以方便地把一些参数传递给线程函数，这真是一个巨大的进步。其次，它有interrupt接口，可以在让线程被中断，有join/timed_join接口，可以绅士地等待线程结束。似乎一切都正是为我解决上面这两个问题问题准备的！但是，问题仍然困扰着我，居然，偶尔的interrupt并不能让boost::this_thread::interrupt_point抛出异常来，而这个“偶尔”实在在是太频繁了！还有，居然，似乎，偶尔join并没有真的等到线程结束就返回了！现有，这个join在等待的时候，会有死锁的现象！ 我狂分特啊！到底是哪里出错了，而且这样的问题还都不是必然重现的，郁闷哇！
