以前一直在使用BCB，主要是基于borland的感情，但是目前的情况看，我得项目不能再跟着borland走了。由于GUI涉及的内容还是不少的，因此转换的过程需要谨慎。经过1个月的评比，参考了很多人的使用感受之后，最终选择了QT，而不是wx。

我先下GPL版本的QT开始学习，安装过程还是狠简单的，中间安装了minGW。然后按照教程里面的Hello Word章节写了一个例子。由于QT没有提供IDE环境，对于习惯于windows下面开发的我还是有一点点不适应。不过倒霉事在后头：（

使用命令
qmake -project
qmake
可以生成3个目录，一个debug，一个release和一个tmp目录，还有3个makefile文件和一个工程文件(.pro)。剩下的make就得借助别的编译器来完成了。开始的时候使用BCB的make，但是提示什么FORCE之类的问题。使用-t vcapp参数生成VC的dsp文件，在VC下面编译，也还是不行。既然本身带了minGW，为什么不用自己的mingw32-make试试呢。最终终于完成了make。不过由于minGW和QT不是安装在一个目录的，为了方便起见，写了个批处理文件：

@ECHO OFF
set QTDIR=E:\Leejd\qt4
set PATH=E:\Leejd\qt4\bin;E:\Leejd\MinGW\bin;%SystemRoot%\System32;%path%
set QMAKESPEC=win32-g++

if exist release del release\*.* /q
qmake -project
qmake
mingw32-make

只要把这个批处理文件扔到你的例子目录下，双击执行就OK！

重构这个名词好像也就是前两年出现的吧，感觉跟我自己理解的优化差不多。前段时间由于时间紧急，我抓紧时间写了一个小程序来用。现在发现这个程序用处还是挺大的，不过当时写的时候没有考虑以后扩展，所以修改以来比较困难。考虑到以后可能还会对现在的这个样子进行扩展，准备把这个软件给重新写一遍，保留一些接口以便以后扩展。

由于原先的代码已经写了不少了，不想重新再写一个，所以直接在原有的基础上进行修改，可以说是重构吧。这次重构需要修改以前的数据结构，把基于STL的数据结构类型改为PyObject的，因此底层基本需要重写，而且准备把这部分从界面代码中独立出来。

经验：函数写的相对要独立一些，类内部的函数也是一样的，不要过分依赖成员变量，这样重构轻松一些。一次改动尽量要少，每次存盘之后最好先编译一把，看看有没有语法错误，防止本次的错误带入到下一次操作中。轻易不要修改数据结构的类型，像我这次由STL转到PyObject的代价还是比较大的。平时写代码的时候就可以考虑重构，不要集中在一起做，有时候长时间做这种工作，会狠无聊的。

今天使用Python来读取二进制文件。直接使用read读取，读入的内容没有错误，长度也是对的，使用了type函数查看了一下内存中的数据类型，发现是str的，初步认为是采用C语言里面的char方式存储。

不过我是要把读入的内容转为内存中的数据结构，需要处理整型等数据类型。由于自己认为是char方式存储的，就直观的认为只要将4个字节的char使用int()函数强制转换一下就没有问题的，不过转换失败。后来咨询了木头，说是要使用struct来处理。查手册，发现struct狠简单，常用的函数就是pack和unpcak。使用unpack函数试试，先google一下，网上面有没有相关的例子代码，发现一个：
print struct.unpack(‘>I’,recv_data[recv_len-6:recv_len-2])[0]
然后就照猫画虎写了一个
(“%s”)%struct.unpack(“>I”, buff[462:466])
不过测试结果却出乎我的意料，读出来的数据不对。同时对>号感到奇怪，查手册struct的下半部分，发现>是表示网络字节序方式，而不是我们x86系列的本地字节序，删除>试试，读出来的结果正确。

以前只是在写网络程序的时候要注意网络字节序问题，现在突然发现，python里面也要考虑字节序，看来python的处理考虑的还是狠周到的。不过以后也要注意二进制的字节序问题了，毕竟网络过来的二进制数据会越来越多的，很多程序中应该考虑这个问题。

现在写的程序中，一直都在集成Python，所以对Python的数据结构比较熟悉了。今天使用STL来写一个不带Python的程序，发现STL的结构虽然轻巧，但是感觉Python的数据结构操作起来更是方便。可能是跟这几天一直在用Python的数据结构有关吧。

其实最关键的地方是文本文件的处理，使用Python脚本把文本读进来，处理，然后直接存为Python的数据结构方式，比使用C++读入文本再使用STL方式来保存方便很多。不过Python的数据结构至少需要带一个DLL文件，这对于小程序是一个累赘啊。

最近的这个项目，是利用Python操作文本的方便和快捷性，嵌入到项目中处理文本文件。目前做的就是将Python解释器集成到程序里面，然后附带一个Python24.dll，不过这样好像还是差一个文件的，msvcr71.dll，开始测试的时候，由于机器里面装有Python24,没有测试出来，到客户那里演示的时候，才发现没有这个文件，幸亏带了Python的安装包，要不然就出丑了。

由于昨天对脚本进行了一些改动，改动的结果感觉差不多，就没有测试直接给演示了，导致演示中出现了一个小问题，改动部分的脚本执行有问题，程序调用返回始终是NULL。开始以为是脚本调用错了，后来以为是缓存的问题，总之排除了很多外在的因素后，最后认为Python的脚本有问题。最后查得得结果是处理传出来的数据结构中，脚本处理有问题，导致单独执行的时候没错（因为测试用的数据结构没有和传出来的匹配），但是集成处理有问题。

开始的时候，就是准备将Python执行的日志集成进去，不过由于偷懒，只做了程序的，没有做脚本的。认为脚本在本地执行了，程序再去执行是应该没有问题的，现在发现还有有些不同，需要处理的。看来把Python的执行日志集成进去是必要的，否则临时修改脚本，出错了就不好找问题所在了。

这几天开始试用SVN，以前只是玩玩，现在是正式在项目中使用了。不过svn还没有使用trac来配合，主要是trac没有ZQ说的那么简单，没有配置好。

常用的就是import，co，ci，add等几个命令，使用起来也还是比较简单的。不过在使用move命令修改目录名称的时候，执行发现目录没有改变，不解，google了一下，发现move命令需要使用commit命令才能真正执行。看来应该是采用了事务方式来处理的。

去年8月份的blog中，我讲解了当时的SVN的安装，并针对原始的安装文件中的问题进行了修正。不过从反馈回来的情况看，我的安装后来就不行了，有一位读者说，按照我的做法，apache无法启动，原来是少copy了一份intl.dll的文件。

今天我准备重新使用SVN进行版本管理，apache和svn都安装好了，然后按照我的原先的blog描述进行安装，发现有些文件的名称已经有变化了，没有那位读者提到的intl.dll文件，不过倒是有一个类似的文件。打开apache的httpd.conf文件，发现里面自动加载了svn的模块名称了（在LoadModule里面），而不再需要手工去将LoadModule的前面的#号去掉了。不过仓库的目录还是需要自己设定的，毕竟安装者还是不知道你的目录的。

准备以后慢慢的使用svn进行有所的版本管理，不过得先熟悉svn先。

现在终于可以开始全心的投入到Python的嵌入开发中了。不过由于好长时间没有接触到Python这块，使得原先掌握的嵌入式Python的知识忘记了不少，现在很多时候还是需要重新去温习一遍。从网上查到的资料，搞Python的嵌入式开发还是比较少的，基本都是作为一种开发的辅助来进行。我现在的参考资料只有Python自己手册里面带的C API部分。不过自己的英语水平不行，很多地方看得不是狠明白，主要是阅读速度太慢了，不过幸亏有代码可以试，这样开发起来感觉难度是不算大的。不过刚开始的时候，可能内存处理没怎么注意，不过幸亏是客户端，实在不行可以重启一下机器，不怕：）不过随着开发的进入，这些东西必须注意起来，因为这些东西如果处理不好的话，会影响软件的稳定性，不过在软件的第一个版本中，还是功能要优先实现的。

今天写了一个C++的代码，居然用上了Python的语法，非常郁闷：）就是将字符串转为Python对象的时候，我弱智到了直接使用PyObject *进行强制转换了，实际上应该是使用PyString_FromString进行的，导致调试的时候老是非法操作。感觉还是基本功不扎实，需要加强。

转自：http://stompstompstomp.com/weblog/entries/72/

这是我在查找嵌入Python文章的时候发现的，主要是讲述一些Python嵌入的Tips。