All Stories
老雷说，画图功能可以让Excel来做，我曾经还抱着试试看的心理在网上找有没有免费的代码可以方便地生成各种柱状图、饼图的，没找到，也实现懒得自己去画了，于是硬着头皮去用Excel了。 VC的程序操作Excel，而且不光是为了存取数据，所以用COM是最正规最有效最理想的方法。如果是用MFC，可以让IDE自动生成其中的某几个接口的封装类，这样的好处是封装得比较高层，使用起来更方便简单一点。如果直接导入类型库，会生成整个类型库内所有的接口和类型的封装，不过是底层一点，最多是用一下COM智能指针封装的接口，可以少处理一些引用计数的问题。 先可以录一个宏，查看VBA代码，就基本知道要用哪些接口的哪些方法了，但实际上如果用VC通过COM来操作，会发现跟VBA的结果经常有些出入。这让我有点纳闷。不过今天整了一天，总算勉强完成任务了。
想起插件的事，如果一个软件具备插件扩展能力，同时又希望其用户自行开发插件，那么这个软件一般说来需要提供一个良好的插件开发环境。纵观Eclipse，MSVS、MS Office等都是这样的，而且VS和Office中的扩展形式除了插件，还有宏，准确地说来，是开发宏的环境是随软件一起提供的，而插件的开发是要用其他工具的，比如VS。而我前面说的插件开发环境，其实对应的是宏开发环境。 这个开发环境简单的做法，应该是一个独立的程序，但与软件主程序之间有很深入的进程间通信，不然调试功能是不可能那么完善的。也有可能是还有一个中间的宏解释执行器，主程序和宏开发环境都是只与宏解释执行器进行通信，同时该解释执行器也有调试功能。这样做的一个明显的理由是，当调试宏时，主程序可能会被挂起，而这时调试界面则要求是活动的，所以放在主程序中是不容易处理的。 Eclipse可能不需要这么做，它也许可以在不同的实例中使用不同的配置，这样可以在一个实例中调试另一个实例。 还有一种比较极端或者不负责任的做法是，不提供开发环境，让插件开发者痛苦去吧。也许用比较高级的脚本语言来做为扩展架构的底层执行器，这个问题的影响会变小，因为脚本语言对调试的需求可能会小于像C++这种编译型语言。但我觉得无论怎么样，提供一点基本的用于调试的设施还是必要的，比如至少可以加入一种打印输出机制之类的。
今天在公司里看到google test和google mock，又好奇心起，看了看，觉得比起CppUnit来真的简洁不少，而且CppUnit没有一个好用的用于插桩的框架，那Mockpp和Mockcpp都有很明显的很影响使用的这样那样的限制和缺点，而google提供的这两个框架则比较好地解决了这些问题。 回到家又上网下载gtest试试，它有msvc的解决方案文件，也有GNU make的makefile。不过msvc倒是能直接编译通过，而MinGW则是不行的，要改些地方。首先要将MINGW的识别宏添加到GTEST_OS_WINDOWS宏定义中，然后在几处使用了SEH的地方，__try/__except都是VC才用的东西的，只要再在编译开关处把MINGW去掉。这样gtest库是可以编译通过了，不过有一个自测试文件gtest_unitest.cc却还是有问题，要加个文件头包含limits.h，这样就可以全部编译通过了。 又顺带看了一下googlemock，它依赖于tr1。在公司里，我什么都没修改，直接用VS2008编译过了，在家里却不行，总是报VC的xtr1common文件中的什么tr1没开启。上网找了下解决方法，加入boost就行了，不过我试了发现从trunk中取到的boost不知为什么不行，最后还是从googlemock的官方网站上下载到一个他们从boost 1.36.0中提取出来的tr1中tuple部分，这样在编译包含路径中添加boost和tr1的路径，就可以编译过了。但它在源代码中明确限制了只能使用VS2005或更高版本来编译，看来要用在MinGW中是有点困难了。
今天把一个用了wxWidgets、Xerces-C++、luabind的工程用bjam写了个构建脚本，可以用MinGW来编译，也可以用VC来编译，这就是bjam的好处，很少需要关心不同编译器的命令行参数。 经过这次实践，还发现alternative的选择原来是要跟它的属性完全对应上才行。比如一个目标，写了toolset和variant以及threading，则在命令行中要把这三个全都设置上，不然它就说找不到匹配的目标。这让我有点头痛，假如我只想在命令行上选择toolset，而让其他两个属性固定死，那怎么办。 不过还算可以了，目前基本能满足实际需求了。
bjam编译Windows下的rc文件不用特别指定，就像其他C/C++代码文件一样，直接放个文件名就行了，它能自动认出来，并调用相应的资源编译器来，只不过生成的二进制文件后缀还是跟代码文件编译出来的一样，不过并不影响最后的链接过程。 对于debug或release下使用不同配置的情况，需要至少每一种情况写一遍目标，同样如果是不同的toolset也这么处理。 今天把一个使用WTL写的工程用bjam系统编译了一把，果然也不是很麻烦，不过需要写不少特定的参数，bjam的默认配置不够用了，所以这样的情况还是不适合用bjam的。简单地说来，适合用bjam的场合，至少是没有一个好用的IDE的情况下。 想起直接在bjam里用wx-config来生成的编译选项，居然会出错，因为wx-config的输出后面多了个回车，用make就没影响，而链接选项在bjam中也没影响。没办法，去网上找到wx-config的源代码，只有一个文件，不过有几千行，稍微找了一下输出的代码，把末尾的回车换行去掉，再试了下，果然可以了。
要在工程的根目录下放一个Jamroot文件，可以没有扩展名，也可以加.jam为扩展名，这样其他子目录下的可以命名为Jamfile了。 基本上是个大小写敏感的系统。 还没找到怎么让它来自己编译Windows的资源文件。 用path.glob-tree可以指定目录来进行glob-tree，如果光用glob-tree，是只能从当前Jamfile所在目录开始全部搜索的。
在编译Luabind成独立的库时，顺便学了一下bjam。bjam在某些场合下挺有用的，如果之前用的是make，再来用bjam，感觉就是用过汇编之后来用高级脚本语言。 折腾了一阵子后，我的感觉就是bjam几乎是完全给boost设计的。其中最突出的特点是，编译器无关。它在这方面做不了少工作，只要指定一个toolset，它就能自动查找编译器所在的路径，而且不用关心编译命令行，因为大部分常用的选项它都提供自己的抽象方式来表达。还有就是它似乎有良好的可扩展性，在boost的源代码目录下有几bjam的工作目录，下面有几个子目录，里面分别存放着一些jam文件，在写jamfile时，可以import模块进来用。 我捣鼓了一阵，把自己一个工程，里面有几十个C++源文件，从GNU make转成了bjam工程。感觉有点新鲜，但总的说来，它应该是适用于这样的场合：工程是可移植的，即要跨操作系统，跨编译器。
写着写着，发现Luabind不是先前想的那样有了SWIG就可以抛弃了的，还是有用武之地的。 主要体现在两个地方。 一、从C++调用Lua函数。Luabind提供了两个方法，在Boost的协助下极其出色地分别实现了调用全局函数和其他可被作为函数调用的对象的调用。这两个方法都以C++模板实现了可变参数类型和可变参数个数的调用，而不是C库中printf使用的那种方法。这得益于强大的Booster::mpl。 二、提供C++中自定义类型的高度灵活的部分封装。用SWIG通过分析C++声明一股脑儿全都封装了，当然可以通过预定义宏SWIG可标识不想被封装的部分，但这需要修改C++源代码，以致于破坏C++源代码的整体风格，而且灵活性明显不行。用Luabind可以随心所欲地把任意一个类的其中几个方法封装了，这个优点是我在看了Luabind中自带的几个example才想到的，比如它演示封装了boost::regex，boost::filesystem，如果想用SWIG，几乎不可能达到目的。
主要的内容生成功能基本完成90%了，于是就研究一下怎么把这html内容通过SMTP发送出去。原来有一个从CodeProject上找的SMTP类，直接用WinSock写的，倒是也可以正常工作，接口也很简单，而且当时沾沾自喜经过自己修改，是可以支持中文的，其实是自己土了。现在只是想把这个类再修改一下，可以直接发送html内容，不过看起来似乎有点儿复杂。 用Outlook Express发了几个邮件，用Wireshark抓来看了看，看得云里雾里。后来找到另外一个示例程序，有源代码，也可以发送html，用Wireshark看了看，发现差别还真大。最后看到一个说明里提到，RFC2110里就是讲这个的，于是马上找来瞄了几眼，终于有点儿理解了。原来Outlook Express在一封邮件里包含了2封邮件的内容，分别是html和plain text的，这样无论对方的客户端能不能支持html阅读，都可以方便地看到真正的邮件内容，当然html中的链接嵌入对象除外。
