All Stories

今天去西安

  一周前就被告知要去西安出差,心里还是有点忐忑的,说起来有点丢人,还是第一次一个人去一个陌生的地方,真正的人生地不熟啊,哈哈。以前去重庆,有同学一起,来深圳,也有校友一起,去贵阳,有表哥和小妞接待,这次可是真的一个人咯。

终于解决Lua中任意使用C++对象

  仰天长啸三声,哈哈哈!一直没想出或找到什么办法可以比较方便地解决这个问题。我的需求是,在C++中随时可能生成一些对象,而这些对象随时可能需要被Lua获取并进行一些操作。  在网上转了很久,看过LuaBind,还有一些文章。只有LuaTinker有一个可以把C++对象映射到Lua全局变量的方法,似乎有点接近了。但实际上离我的需求还是有点距离,比如它需要由C++代码知道这是给Lua用的,并主动把对象映射过去,而且是映射到Lua的全局变量中,通用性不够。我希望C++代码可以不跟Lua交互,其次,应该由Lua主动去获取它需要的C++对象,这样Lua可以自己决定把这个对象保存到什么地方。  今天又看了一下SWIG的文档,发现SWIG对Lua的封装做得实在太好了,它可以封装出自定义类型的指针,例子代码中以FILE *作了示范,想了想,我在C++中写个函数,返回相应的对象指针不就行了!试了试,果然可以,这下终于搞定了,可以继续写编辑器了。昨天还在想,有一部分Scintilla的初始化工作,代码好长,虽然初始化内容是保存在配置文件中的,但是配置项多,而且互相之间比较独立,C++代码仍然需要一个配置基一个配置项地写,我就觉得这部分应该交给Lua去做。这里Lua的功能除了原有的保存配置的功能外,还兼任了使配置生效的责任,而且仍然保留了原来配置文件的不需要重新编译主程序就能修改行为的优点。这个思路是对的,但技术难点就是Lua如何操作那个编辑器,这下好了,没问题啦,SWIG真是个好东西,还要Luabind之类的C++ Wrapper干什么!

我真是个换肤论者

  之前说到,用多了chrome,竟然不知不觉地想着firefox的界面也想跟chrome一样,说干就干,先去找theme,要能尽量模仿chrome的,还真找到一个chromize extreme,不过它只能支持3.1b1以上版本,没办法了,我现在是3.0.6,只好去重新down了一个3.1的装上,还是像以前一样,用命令行参数,将配置目录指向3.0.6的目录下,这样就可以使用3.0.6中已经有的一些东西,不过有些扩展不兼容,暂时不管了。装了chromize extreme后,挺像chrome了,除了多了个标题栏。找到一个hide caption扩展,不过发现它不能用在3.1版本中,于是另外想办法。最后只好用custom button扩展,加上一段脚本,叫max的脚本,会自动将firefox弄成最大化并隐藏标题栏。  搞定!界面看起来真的像chrome,感觉舒服多了,哈哈,就是不能用3.0中的一些扩展了有点遗憾!

傻掉了

  突然发现,怎么Firefox有标题栏,怎么有菜单栏,怎么这theme就不正常了呢!使劲点了几下菜单,也没变化,切换了一下theme,重启firefox,菜单栏不见了,再切换回去,怎么标题还在!  突然想起来,这标题栏似乎一直都在的!是chrome用多了吧,傻掉了,汗!

黑社会?

  8点钟才从公司出来,坐上B666回住处,也不算太晚。快到小区门口的公车站时,我已经站起来走到门边,一辆SUV却超上前拦住了公车。从SUV下来五六个30来岁的男人,都是圆寸头,拍开驾驶室的窗很嚣张地对司机说,叫他以后不准再开,要是明天再被他们看到要怎么怎么的。这样捣鼓了几分钟,终于走掉了,我还一直担心他们会不会上车来抢劫。  记得从上中学开始,每当说起以后娶妻生子的事,我就有点烦躁和恐惧,我总是担心自己的小孩没教好,变成流氓。我妈知道我的想法后,曾也和我说过,只要好好管教,是会好的。今天看到这些人,我又想起这些来,不禁又想,这些人的家人都是做什么的,他们有没有父母,有没有妻儿。  这个世界,真让人憎恶。

开始使用wxWidgets进行界面开发

  半生不熟地用着wxWidgets,全是照着代码改的,勉强能运行起来,不过似乎用gcc编译出来的release版本有时候会报错,不知道是哪里出的问题!可能是哪里资源没正确释放什么的吧!  界面的框架算是搭起来了,排除掉那个报错的bug就比较完善了。接下来完成插件扩展机制,一大块功能就可以用脚本完成了。

差不多封装完Xerces-C++了

  其实只是封装了其中很小很小的一部分,DOM的那部分,DOM中DOMElement相关的那部分。接口是模仿那个同事的MSXML封装类来的,应该说,只有最初的灵感是来源于那个MSXML封装类的,后面真正用得最多的部分,实际上已经是被我修改过的。其中最有用的部分是,对属性和文本内容的设置和获取,针对不同的数据类型作了特化,以及对NodeList部分增加了iterator来适配STL算法。  对于这个封装的意义,或者说价值到底有多少,自我感觉,至少在现在手头这个项目中,在boost::bind、boost::lambda配合STL算法的联动操作下,让代码少了好些,不过也许带来的问题是,可读性变差,以及不再去思考是否有其他更好的方案的惰性增加。

终于搞定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库,准备工作还那么麻烦啊!