All Stories
Write well documented code
在开始决定使用doxygen后，一直有种隐形的强迫之力，促使我为自己写的代码作好注释。今天经过一番小小的努力后，到晚上加班时，终于可以warning free地用doxygen为我那个工程生成暂时令自己还比较满意的文档了。心里不免有些小小的成就感，心想这样的场合下写的代码，就是应该这样作好注释，为文件、类、变量、函数等等各种元素进行标记。 现在我用doxygen的方式还是比较落后的。先用doxywizard生成一个doxfile，然后把这个doxfile添加到VC的解决方案里，注意保存路径也是要和解决方案一起的，这样以后方便。再在VS的IDE里有个外部工具菜单项，添加一条指向doxygen.exe，参数当然是doxfile，路径是和解决方案的一样，运行目录也是和解决方案的一样，这样就在菜单上多出一项doxygen来。为图方便，可以写几个自动添加注释的宏，并把它们绑定到快捷键上去。目前我自己用的有为文件、类、函数以及普通目的几种定制了宏，定制宏的目的是一方面可以生成符合doxygen要求的格式注释，另一方面有些内容是可以自动填好的，比如文件名、作者、日期等等，当然这样的宏还是很低级很落后的，最好是能把这样的功能跟Visual Assist X之类的插件集成在一起，可以自动识别出函数名、类名等更高级的信息，并生成相应的注释，不过现在在还没找到更好的办法之前，就先这样将就一下吧。最后就是点击那个菜单项，运行doxygen，生成文档。 doxygen提供了很多选项，也支持非常多的关键字。在使用的时候，我也是一边摸索一边尝试，唯一的资料就是它自带的文档，在开源的项目中算是很不错的了。不过始终让我觉得郁闷的是，为什么中文的老有问题，好在现在有一个别人的自编译版本，1.5.1的能比较完整地支持中文了，先暂时这么用着。 另外有些经验。对于同一项目中不同目录下的同名文件，可以通过写路径来让doxygen区分出两个文件的不同，而且要注意的是，这个路径它是大小写敏感的。对于文件名唯一的文件，只要写出文件名即可。 注释写在头文件中比写在实现文件中要好，而且最好声明和实现完全一致，比如函数参数列表。注释中标识参数时，只要写参数变量名即可，不用写定义的类型，而且变量名要和声明时的完全一致。 doxygen支持todo list，它会把它单独列出来，比较方便，当然现在的MS和CodeGear的IDE也有对todo list支持。 最好对每个有点作用的变量、函数、文件、类（结构、枚举）、宏定义等都作注释，这样看起来比较舒服。 对于ATL中使用STDMETHOD(xxx)(yy,zz)这类形式的声明，如果doxygen认不出来，可以改成STDMETHODIMPL xxx(yy,zz)这样的形式，就可以了，不过我没试过其它选项，说不定哪里设置一下，前面的那种形式就能很好地识别出来了。 最好装上Graphviz，让doxygen使用它来生成类图、被调用图，很好，很强大。 还有就是要坚持，要循序渐进，在新定义一个变量，一个类，一个函数时，就给它添加注释，嗯，这样就能写出一份well documented code了！
托小妞买了条项链
今天小妞把项链给了我。这是我前些天托小妞去香港的时候带的，周大福的，在我的要求下，据小妞说这链子是加长18寸的，应该能够我妈带了，呵呵。原价是一千一，可以打九折，就是九百九了。其实最开始的时候，我还以为只要三四五百就够了，后来跟小妞说的时候就随口提高了上限，说一千以下就可以了。看光泽还是不错的，嘿嘿。 小丫头给我传了些她的照片，脸好圆呀，呵呵，越看越觉得可爱。
做个hash工具
一直想自己写一个计算hash的工具，而最无耻的是，我对各种密码学意义上的hash算法根本不了解，只知道有这么个东东。不过现在流行的hash算法网上有一些现成的代码，C和C++都有，比如著名的Crypto++、LibTomCrypt等等。 本来跟hash算法是完全没有交集的，平台根本用不到，最多也就是直接LoadLibrary系统自带的CryptDll.dll，里面有计算MD5的函数，这是在好些年前就知道了的，也一直丢在一边。现在因为要做一下文件共享的东东，其中避免不了的是唯一标识一个文件，而一个良好的消息摘要算法就是一种可行的方法。鉴于网上早就出现了一些针对MD5碰撞的实际例子，所以我就有点不甘心只使用MD5算法，于是把LibTomCrypt的代码抠出来封装成C++的样子。这样的消息摘要算法计算过程一般分为初始化，更新数据，得到结果3步，所以可以把每个算法都封装成一个单独的类，每个类都向外提供这3个方法，这样只要根据需要可以以相同的计算逻辑得到最后的结果。 封装好了各个算法后，再提供一个类，封装更高层次的功能，比如计算一个文件的hash值。文件需要打开，然后每次读出一部分数据来计算，最后才得到一个结果。这样的逻辑不需要为每个算法类都写一遍，写到单独的类里即可。至于该类与各算法实现类的关系，比较OO的做法是，用继承，所有的算法类都继承自该类，就自然而然地有该方法了，但似乎还需要增加3个虚函数，这样父类的方法才能调用到子类的方法，这样就多了点运行时间和空间上的开销，尽管不严重；另一个比较GP的方法是，把该类写成一个模板类，而各算法实现类做为模板参数，这样就可以省掉因虚函数引入而带来的开销了，当然带来的成本是用户使用这些类时，需要同时知道这个类的存在以及各个算法实现类的存在，而前面讲的偏OO的方法是只需要知道算法实现类就行了。 上面解决了一个向外提供接口的问题。接着又有一个新的问题来困扰了我两天。因为上面已经有一个类是对于每个算法实现类都知道其存在的，但我又发现其中有几个算法实现类中的更新数据方法逻辑是完全一样的，要把数据根据当前算法的实际需要拆分成多块进行压缩运算，所以只是其中调用的压缩算法不一样，数据长度不一样，这样的情况也是代码复用的一个场合。但是开始的时候，我不知道应该把这段看起来可以公用的代码放到什么地方。同样，比较OO的做法是写一个基类，让这些算法类继承过来，同样需要一个虚函数，因为会有一个压缩运算过程，不同的算法是不一样的，虽然函数名可以一样，所以也多了一点开销；另一个当时很不想用的办法是，像LibTomCrypt中一样，把这个过程定义成一个宏，在这些算法实现类里都写一句这个宏调用，就没有虚函数带来的开销了，但我觉得这是C的做法，而不是C++，这个场合这种做法很丑陋；后来偶然在QQ群里看到别人谈及模板应用的一种方法，得到灵感，就像WTL那样的静态多态就可以，仍然需要一个基类，但基类是个模板类，而模板参数就是自己这个算法实现类，这样通过基类中的方法仍然可以调用到子类中的方法，但又没有虚函数的开销。基本解决这个问题！ 后来又遇到一个问题，不过没有解决。HAVAL算法，可以有3、4、5轮计算，不同轮数的计算中间的步骤也会有点小差别，每种计算最后的长度可以是128位、160位、192位、224位和256位。照理，前3轮或前4轮的计算通过宏定义等方法可以在某种层次上封装可相同的逻辑，这样3种算法就应该可以共用一部分代码，可是实际上，用宏定义的方法不行，第2次修改过的宏定义不能影响到上面的应用了宏调用的地方，所以实际上代码共享不了，只好重复写了，以后想想办法能不能改进。 Panama hash算法的资料好少，Crypto++的实现又比较复杂，看不懂哦！
什么程序可以集成脚本语言解释器
每次看到按键精灵，心里总有种奇怪的感觉，这个东东，忽悠了好多菜鸟，也赚了不少钱吧，可我心里却觉得这不值，是忌妒吗？ 最近想着，做什么程序可以集成脚本语言解释器呢！ 有些情况是可以预见得到适用的，比如这些天突然想学学围棋，于是在网上找了下打谱的软件，这种软件就适用。有个叫StoneBase的打谱软件是国内做得比较好的，但它并没有第3方可扩展性，照我的想法是，对于要兼容多种格式的棋谱文件，就可以用脚本来解析，规定一种中间格式，假设是标准的SGF，把所有其它格式在主程序的主动触发下都用脚本转换成中间格式。我暂时也想不出其它更多的地方可以用脚本的了，偶然看到它的论坛上有人发了个可以自动下载TOM网站上公布的棋谱文件，于是我就想，是不是可以干脆直接支持外部工具，但是转念又一想，都已经是外部工具了，就不需要集成解释器了…… 另外还有种情况，最近因为要写Socket程序，所以想到如何方便地调试这类程序，特别是对于客户端和服务器端都还没写出来的情况下。于是我想写一个辅助调试socket程序的工具，大概的想法是，它可以做为一个主动去连接的客户端，或者是被动接受连接的服务器端，连接上后，可以看到接收到的内容，还可以由用户手动输入内容发送，这种情况下，脚本的应用就比较有实际意义了，比如可以把接收到的内容交给脚本处理一下，脚本再根据实际情况发送一些内容，这比较适用于调试协议，像http/ftp等协议用脚本就能实现一个简单的原型。这个工具我已经想了很久了，但只建了个工程，却还没开始做，如果做好了，一定是个很实用的东东。除了这样的客户端和服务器端功能外，还要有用Detours静态hook创建进程，动态注入attach到已有进程，用WinPCap或Raw Socket（其实有了WinPCap就不需要了）抓包这几项功能。静态hook和动态attach是为了看进程调用WinSock API的情况，而WinPCap抓包就是一个普通的抓包功能，因为如果光是做抓包功能，我想我是做不过那些专业的做了好多年的工具的，如IRIS、CommView以及开源的Wireshark等等，所以重要的是前几项。又扯远了，脚本在这个工具里还可以用于解析帧结构、协议等等。 当然还有种情况，就是用于像按键精灵这样的工具上。 现在有4种脚本语言是我比较感兴趣集成到程序中的，分别是Python、Ruby、Lua和TCL，但实际上TCL与前面3个放在一起并无多少作用了，它的应用面比较窄，又缺少现代语言的一些元素，而且没有什么特别有优势的特性。Python和Ruby这两个大而全，且语言特性丰富的脚本已经能满足大多数场合的要求，而Lua则完全是看中它小巧快速，特别适用对性能有点要求的场合。Boost中有Python的粘合库，Lua以前有LuaBind和LuaTinker，但好像没更新好久了，至于Ruby我还没有了解。但我想，我总有一天会自己来分别写一套简单的，自己够用的库的。
感觉到有点压力了
今天上午，一个同事打电话，问些关于某个名义上由我维护的工具的事情。问题的缘由是，该工具现在使用的时候有些不正常，于是我就推脱说现在忙于另外一个项目。最后她就生气了，其实我心里也不爽。下午的时候去看了看现象，其实我觉得不一定是工具有问题，可能工具使用的机制就是有问题的，如果是机制有问题的话，就一时半会儿也不好解决了。这个工具说原理，其实并不复杂，无非是个函数hook，只不过同我们平常接触到的不一样，它是针对运行在单板上的软件的，单板运行VxWorks操作系统，使用PPC的CPU，用Tornado（其实是GCC 2.9x）编译，应用的典型场景是，在运行Windows系统的PC机上写好代码用Tornado编译一把，然后用这个工具把编译好的东东上载到单板上，并通过用户操作给指定的函数hook一下。有了hook，当然是有unhook操作，问题是有些情况下，unhook不成功！据了解，出问题的情况是分hook什么函数而定的，有的函数hook了就很容易直接宕掉，我粗略估计了一下，这些函数很可能是因为被调用得太过频繁，有些操作来不及做，就阻塞了，比如要把消息发回给PC上的显示终端，于是很可能就宕掉，但这也只是我的猜测。 另一方面，现在手头的这个项目，渐渐时间少起来了，我要争取本月底前拿出一个基本可用的但可以很不完善的原型出来，至少可以让那些头头们不要总在那里烦人。不过真的动手的时候才发现，其实有不少问题是很花时间的，当时的构思是不够仔细的，不够推敲的。 有点烦啊！ afei打电话来说下周就要出去了，估计走之前也没时间再出来了。
真是没用
上周六下午无所事事，就跑去健身房耗了一个小时，本来只是跟以前一样踩一下车，跑一下步的，后来去做了几个仰卧起坐，要求是做4组，每组15个，结果我只做了2组就做不下去了，后来好不容易又死撑了10下。当时就觉得挺虚的，就偷偷逃回家了。过了一晚上，腹部上的肉疼得站直不了了，像是要被撕开一下。今天还是痛，虚啊，听室友说他上次这样痛了3天才好，晕！
在编辑器方面做点事
跟TextPro的负责人交流了一下，发现分歧还是挺大的。他们只想做一个普通的处理中文文本，有正则表达式支持查找替换，还有一些简单的转换处理功能的小程序就可以了。而我原本还以为要做一个通用的文本编辑工具，至少类似UltraEdit、EmEditor之类的，只不过对中文处理增强了。分歧很大，我只好放弃了，不如自己玩自己的。 看了一下鱼鱼桌面秀，存在字符编码问题，我的系统上如果安装路径里包括了中文，就运行出错，处于不可用状态。其实我只是想看看它的插件编写环境，原来它用的SynEdit，还是比较完善了。晕！
doxygen是个好东东
doxygen真是个不错的东东，现在都有点爱上它了，特别是对于现在我这样的情况，我还是随时准备着要把手头的代码交接给后来的人的，所以为了减少沟通交流的时间，比较详细的文档是很重要的一步，而对于缺少设计文档的项目来说，源代码即是最好的文档。这时doxygen的作用就很明显了，在它的帮助下，可以很方便地扫描出当前项目下所有源代码中类的依赖关系，文件依赖关系，类说明，文件说明，方法说明等等等等！我现在用的办法是，先生成一个doxyfile，添加到项目中，在VC的外部工具中添加一项，调用doxygen生成该项目的文档，还是比较方便的。不过也遇到些问题，最奇怪的莫过于中文的支持了。我从官方网站上找来的1.5.x对中文支持都有问题，但从公司网上找的一个人家自己编译好的却没问题。另外一个问题是，对于不同工程中同名的类，它会只留下一个，丢掉了另外的，这就不好了。对于不同工程中的同名的文件，倒是可以通过指针建子目录来解决。不过也许是我还没用好，说不定是哪里的设置问题。
