仰天长啸三声，哈哈哈！一直没想出或找到什么办法可以比较方便地解决这个问题。我的需求是，在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，全是照着代码改的，勉强能运行起来，不过似乎用gcc编译出来的release版本有时候会报错，不知道是哪里出的问题！可能是哪里资源没正确释放什么的吧！
　　界面的框架算是搭起来了，排除掉那个报错的bug就比较完善了。接下来完成插件扩展机制，一大块功能就可以用脚本完成了。

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

　　再次尝试，终于可以在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有点遗憾！

　　还是搞不定，郁闷！
　　首先我用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库，准备工作还那么麻烦啊！

　　在复杂的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果然可以正常运行下去了，唉！
　　又靠了次老外。

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

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

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

　　真是捉弄人的命运啊！有句话说，命运负责洗牌，而我们才是玩牌的，牌太差，无论技术如何，都是于事无补的。
　　今天在公司里用错了_tcsncpy和_tcsncat，因此引发的bug找了半天才明白原因，汗颜。
　　另外，Launch里好严重的内存泄漏，确实，都是些很低级的失误，review很重要。

　　今天终于解决了向SQLServer2005存xml时使用的字符集的问题了。
　　年后第一天上班，看到年前一个邮件，说是有个文件导不进去。拆下来跟踪了一下，发现是中间生成的xml文件不完整，通过简单的试验，直觉告诉我是字符集的问题，因为我将这xml文档的字符编码设成gb2312 了，而鬼知道别人会写些什么特殊字符进来。把文本粘贴到UltraEdit中看了一下，果然有一个非gb2312范围的字节。我想，这种情况都出现了，无论如何都不能再继续用gb2312了，只能往utf-8之类的方向去考虑了。实验证明，以utf-8编码的xml文档是完整的，可是又回到一年前的问题，utf-8编码的xml文档写不到SQLServer 2005中xml类型的字段中，只能写gb2312的。
　　实在没办法，这方面没有人可以提供相关的经验指导，只好去看SQLServer2005的online help，好在是中文的，随便翻了一会儿。中间联想到，会不会是MSXML保存时并没有真正转换编码，实际上当然不是。又联想到，该不会是因为没有BOM 吧，结果我没有去试。后来偶然看到其中一段说明，可以用utf-16，而且不在乎有没有BOM，如临大赦啊！
　　用ADO写回去时，先读出整个文件，因为开头的BOM的原因，需要再用SysAllocStringByteLen生成一个BSTR，不能直接用_bstr_t，再填回数据库，就可以了！