All Stories

终于搞定boost::program_options

  再次尝试,终于可以在WIND中使用boost::program_options了,其中付出的代价是,不能使用STLPort了,因为最直接的原因,不知道为什么,在release模式下,编译就会出错!  这之前提到过,用vc9编译boost时,会只生成几个静态链接库,而且这几个静态链接库实际上并不能正常使用,现在发现原来只要在编译前,在命令行环境中设置好vc9的路径,也就是先运行一下那个vsvars32.bat,就再进行编译就可以了。  这次编译我在命令行中添加了--buid-type=complete,耗时巨大,至少1个多小时还是因为磁盘空间不够而结束了。不过确实生成好各种类型的链接库,以目前program_options来看,共有7个库,其中2个是动态链接,分别有debug和release两个模式下的,从文件名中可以区别开来,debug下的文件名中有gd字样,而release下的是没有的。静态链接的库文件共有5个,都是libboostxxx.lib的形式,可以看到其中s表示编译器的runtime是静态链接进来了,gd则还是表示debug的意思,mt则是多线程的意思。所以照这个原则推测,其中有一个是单线程静态runtime链接版本,不过这对我来说,也没什么用了,一般说来,我写的程序肯定是使用多线程版本的runtime的。  终于搞定了,除了不能用STLPort有点遗憾!

搞不定boost::program_options

  还是搞不定,郁闷!  首先我用vc2008编译从svn中取出的boost代码,总是有问题,只能生成一些libxxx.lib,没有生成动态链接版本,这个问题在boost正式发布的版本中是不存在的,真奇怪。   其次,无论是正式发布的还是从svn中取出的代码,编译的boost::program_options,在与STLPort一起用时,是必定出错的。debug模式编译基本能过,但链接死活不行。release模式则索性编译不过,这个问题在取消STLPort时,就不会存在。但是如果不用STLPort,在链接时,会报符号冲突。   如果实在不行,也没办法了,只好不用boost的需要编译的库了。boost中大部分的库是header only,这总算让我觉得比较欣慰。不过昨天看到Boost.Log以提交review了,而且看了一下它的文档,需要依赖了boost中的好多库,其中好几个需要编译的,比如boost::filesystem、boost::system、boost::date_time等等,郁闷,一直在等着boost出一个log库,准备工作还那么麻烦啊!

强大的Firefox,强大的扩展

  在复杂的Internet环境中,用惯了firefox,用惯了它的扩展后,再也不想用其他浏览器了。这两天又装了几个扩展,太好用了。  noscript,自动禁止了一些无用的页面脚本。Coolpreviews可以在鼠标指针移到超链接上时,自动弹出页面预览窗口。FireGestures,就是现在在很多软件中流行的鼠标手势。  像chrome这样的实验品,我最多只是在局域网环境中用一下,一来忽略了外网环境中特有的复杂性对它的过高要求,二来它的超快速度在局域网中也能更好地体现。

又靠了次老外

  前不久为了使得MSXML输出到文件的内容有良好的缩进格式,在网上又转了一圈,最后终于在一个老外的论坛里看到一段代码,使用SAX的方法,果然可以几乎完美运行。再也不用以前找到的使用xslt的方法了,使用xslt的方法是很久以前在国内哪个网站上找的一段javascript代码,自己翻译成了C++的,最后效果不是很令人满意,主要有两个缺点。一是文档开头的处理指令没了,要在额外添加,二是对于没有文本内容的节点,它还是会添加一个结束标记,累赘冗余。  这两天在写WIND时突然遇到的问题,本来只是使用STLPort替换了VC9自带的STL实现,用着也没什么问题,后来想试试boost::program_options,结果在编译时,报boost::program_options的lib跟WIND编译时使用的标准库不一致,一猜就晓得是因为当初编译boost::program_options没有使用STLPort编译,于是想重新编译一把。翻了好几遍boost自带的文档,也没找到具体的方法,在网上又转了几圈,还是没发现有效的方法。今天又是偶然在一个老外的论坛上,看到一个回复,简单试了试bjam果然可以正常运行下去了,唉!  又靠了次老外。

小妞说我麻木了

  今天突然说起情人节来,小妞问我有没有约mm,我说我一到关键时刻就哑火了,小妞就说约一下又不会死人,我说没有想约的人,是不是我要求太高了。小妞就说觉得我是麻木了,什么样的人都觉得一般。我无语。也许吧。

孙同学好贤惠

  今天是元宵节,据说今天晚上10点多将是近50多年来月亮最圆的一次。下班后跟F还有孙同学一起去超市买了点汤圆,然后回家自己煮。三个人吃两包汤圆明显是过量了,最后实践证明,我们顶多只能吃掉一半。当然我们也煮了一点米饭,一人不到一小碗,不过也刚好用来调味,汤圆毕竟太甜了。  吃完后,孙同学又一次把我的厨房大清洗了一遍,灶台上厚厚的油渍也被擦干净了。我开玩笑说,你是不是现在故意来刺激我的啊,以前怎么没发现你有这么贤惠啊!她就说,可惜了吧,后悔了吧。呵呵!  真的很有点心灰意冷了,要撤退了!

sqlite3编译脚本有问题

  这两天才发现,用msys运行configure生成的makefile是直接编译链接有问题的,最后链接的时候总是报找不到一个什么sqlite3Backup函数。今天在源代码文件中查找了一下,发现这个函数是在backup.c文件中定义了的,所以代码有问题的可能性不大。于是看了一下生成的makefile文件,赫然发现没有编译backup.c的动作,加上后,再make一把,果然通过了。  看来sqlite3的configure脚本没有跟着更新啊!

炒点小菜,喝个小酒,惬意人生

  去超市买了点儿肉和菜,回来哧哧喳喳弄了大半个小时,整出3个小菜来,跟同屋的那个江西老表一人倒了大半小饭碗的女儿红,打开电视,看着国内国际时势政治,摆下龙门阵,点评下天下时局,人生真是惬意啊!

有点想通了

  昨天又看了一下《Contributing To Eclipse》,思路有点清晰了,应该有一个任何地方都能访问到的地方,Eclipse中叫插件注册表,存放着所有插件的描述信息,这样无论是核心还是插件,都可以随时读取到与自己相关的插件的所有必要信息,实现相应的功能。  之前还疑惑,与界面相关的插件处理流程会自相矛盾,现在看来应该能解决了。首先需要确认一点,暴露被扩展点的,无论是核心还是插件,都可以从插件注册表中读取扩展的信息,比如菜单项名称,这样就可以添加一个新的菜单项,以及维护一个处理关系,Eclipse中有个某某proxy的机制,这形式不重要,关键是暴露被扩展点的那个部分应该在添加了新的菜单项后,能在菜单项被点击时,准确地知道哪个菜单项被点击了,并依赖插件注册表找到对应的处理流程,以我目前的情况而言,即对应的Lua脚本文件,Lua脚本模块名称,以及处理函数名称,然后将这些信息提交给插件运行模块来运行,插件运行模块则又要与插件装载模块合作,如果运行时发现没有对应的模块或函数,则要先装载对应的脚本文件到解释器中。