All Stories

觉得自己很可怜

觉得自己很可怜

  觉得自己很可怜,唉,状态很差,生活、工作都很糟糕。今天去汇报工作进度,被领导认为这两周来没做什么事,郁闷!遇到个变态的领导,让人如此无语,用小妞的话来说,有过这样的经历后,以后觉得什么人都是挺好的了。  今天又因为忘了std::map的自动排序功能,而花了不少时间去修正那些bug。我把句柄作为key,该句柄上的标题文字作为value,本来想这样的结构用std::map挺好的,结果整了好久才发现插入容器时的顺序跟容器内的节点顺序不一样,才猛然想起来,这个std::map会自动根据key的值排序一把,而我恰恰不需要这个特性,于是想起去年,做编辑模块的语法提示功能时的情景,用了std::vector<std::pair<HANDLE,CString> >的结构,有一点std::map的样子,但又保留进入容器的顺序。  代码真的越写越乱了,现在连接口都是混乱的了。相似的方法名,容易产生歧义的参数列表,以及更多耦合的类划分。为了完成功能,我只好不管这些了。还有,我似乎也有点完美主义,上周讨论下来的结果,那个方案,我总觉得太土太不专业,总想用另外一种我自以为要好得多的方法来实现,但是脑海里另一个声音却是“先完成功能,不要管实现得好不好看”!  在公司论坛里看到一个monaco字体,等宽的,发贴的人说是最好的编程字体。开始我还不以为然,看到另一个人解释说什么叫好的编程字体,一要等宽,二要容易辨别o和0,1和l,剩下的则是见仁见智,觉得挺有道理的,虽然贴图上的样子看起来并不好看,我还是下载下来试用一把,把VC2003里用了一年的FixedSys换掉了,感觉还是挺爽的,看来大概是用了太久了,审美疲劳了。

Opera确实比较快

Opera确实比较快

  这两天还是照平常一样,在网上看小说,因为看的都是盗链,看到后面的章节一般都是截图的。昨天偶然开了一个Opera 9.51,猛然发现在它这里图片出来的速度比Firefox里快多了,很明显的现象。不得不承认,Opera在这方面的努力真的很有成效。而Firefox对现在的我来说,最大的让人不满之处就是它速度实在慢了点。如果换作以为,我肯定还会再加一点内存占用过大,不过现在1.5GB物理内存使得我不再特别关注这个缺点了。不过速度慢这个缺点却是没有明显的可以弥补的办法。  都说Chrome的V8引擎已经作了极速优化,但是总的看来chrome还是个半成品,我已经太过习惯于添加了各种扩展的Firefox了,所以Opera也还是没能正式作为我的主用浏览器。而我就只能希望Chrome的出现能刺激一下Firefox开发团队,好好优化一下代码,提高点效率。

开始使用WTL进行界面开发

开始使用WTL进行界面开发

  有点受不了MFC那比较累赘的几个在超大dll,同是Windows平台下做GUI开发,我只好选择了WTL。其实我已经比较习惯MFC那套东西,并没有发现多少网上说的种种使用MFC的不爽,相反我觉得还是挺安逸的,甚至对于使用了四五年VCL的我来说,MFC也没多少不方便的,虽然相对于VCL来说,MFC根本算不上可视化,但我也不清楚为什么自己仍然能这么乐于退回使用这种原始的framework呢!现在唯一让我觉得不爽的竟然是它要拖几个dll文件,也好,刚好学习一下WTL。对于目前我的状态来说,最大的困难是可参考的资料过少,市面上还没发现哪本图书是讲怎么使用WTL的,唯一的一份教程则是CodeProject上那流传甚广多少年前的那几篇文章。  之前也用过WTL写过一个对话框程序。还有一个输入法辅助程序,本来期望是用它来做皮肤生成器的,结果和众多其他我写的程序一样,只是开了个头,然后就丢下了。如今要写一个比较大的程序,我自己也估计不好规模会有多少,猜一下大概C++代码行会过万吧,另外我希望大部分逻辑都是使用外部脚本扩展来完成。  虽然几乎一点经验都没有,但还好有现成的代码可以参考,特别巧的是,我那程序中也需要一个代码编辑功能,本来就想好是用Scintilla的,但是我不懂如果在WTL中使用这种自定义的窗口,刚好就可以抄袭那些代码了,哈哈!  编辑器能正常显示出来了,接下来要把TabbingFramework和DockingFramework加进去,之后再考虑其他问题!

强大无敌的开源软件

强大无敌的开源软件

  今天偶然看到一篇blog,讲述了chrome用到的各种开源代码库,至少有25种之多,让我不禁感叹,开源真是个好东西啊,真是软件界的共产主义啊。我内心是很认同这种做法的,觉得理所当然,而且自己平常也有这么做的倾向,只不过限于自己视野和认知,很多时候并不知道有合适的方案可供选择使用。  以后要多多了解这方面的内容并在现实中加以应用啊!

格式化显示流程图完成

格式化显示流程图完成

  经过最近几天的努力,终于基本实现了通过dot的帮助,格式化显示流程图的功能。还记得当天晚上因为发现dot的功能,兴奋地睡不着觉。前天完成了把XML格式的数据转换成dot文件,再用dot生成PNG和SVG功能,昨天又换回GDI+,把PNG图片显示出来,今天则是把SVG自行解析了一把。dot生成的SVG文件确实是用UTF-8保存的,但是一开始发现用MSXML死活加载不上,后来慢慢定位发现是最开头位置有一句DOCTYPE,把这句删了就能好好地加载了。我估计是我没用好MSXML,不然也太扯了吧。不过这里我也懒得去追究了,直接处理了一把文本,把那句删掉了。然后装入,果然所有需要的信息都解析出来了。中途还遇到个小麻烦,发现识别鼠标位置总是有时行有时不行,还单步跟踪了好久,后来一狠心先把所有节点的坐标打印出来,再对应点击的坐标来看,到底是实现逻辑还是哪里有问题。发现原来就是一个单位转换的错误,一时疏忽了,SVG里都是用磅表示的,而这里我要的是像素,乘上这个比值就可以了。  离最后期限发布还剩下的一个大问题是权限。权限系统当时考虑地太过简单了,不过也归结于当时的需求或者设计都没有想到现在会变得这么复杂。当时确实只想到了某个组织下属某些组织或个人,而根本没考虑某个人会需要作些特别的操作。现在的一大问题是,某个人可能同时分属于几个不同的组织,另一大问题是某个人需要有一种角色,管理员角色,这样可以拥有一些特殊操作的能力,还有一大问题是,在客户端对组织结构及角色进行修改后,该修改要让所有客户端知道。现在的做法很明显很难适应这些需求了,因为我把组织结构保存在一个配置文件中,而该配置文件是放在各个客户端中的,所以修改只在本地进行,不影响其他客户端。没头绪啊!  下午的时候,算是阶段成果汇报,中途我溜了出来透透气。老大说我做这个程序,很有些想法。让我不禁有点得意,同时也特别悲哀,原来我这么容易满足,只是别人这么一句普普通通都算不上夸奖的话,就让我觉得高兴了。

exchndl.dll提取出来了

exchndl.dll提取出来了

  昨天好不容易咬咬牙,把捕获未处理异常的功能提取出来封装成一个dll了。这是一个很简单的功能,所有的代码都是现成的,我只不过是把它从源代码复用的方式改成了二进制复用。当时公司里的同事说我这源代码复用的方式太落后,想叫我改成一个COM组件。而我又恰恰对COM很反感,所以一直都没动手。这次在一体化平台中涉及到2个exe程序,而只在一个主程序中用到了这个功能,有一天收到一个报告,另一个exe程序也会崩溃了,所以就有了要分离出来的想法。  提取成dll我当然不会用COM来封装,而是学MinGW中的exchndl.dll的方式,移植的主要工作是把MFC中的CString类都替换掉。这花了不多的时间,然后放在WallpaperHelper中进行测试。  除了记录了系统简要信息和调用栈信息,我还另外加了几项也许有点用的内容,包括当前系统中所有的进程、环境变量、当前进程所有的模块、所有线程信息。本来还想加些其他内容的,比如当前系统的服务信息、系统设备驱动程序信息、当前进程的所有句柄、所有文件映射、所有窗口等等,不过想到暂时这些信息也不是很重要,而且这样会让生成崩溃报告的时间更长,先还是放一边吧。  最近我想我真的是工作压力大了点,昨天下午睡午觉,梦到了很多乱七八糟的事情。最让我觉得气愤的是,居然梦到有个老女人,对我的工作指手划脚的,然后旁边两个同事也不知道在干吗,跟现实中的很相似。真是日有所思,夜有所梦,愤慨啊,竟然我的梦都被人这样强加干涉了!

使用iconv转换字符编码

使用iconv转换字符编码

  昨天从网上查到,要让dot支持中文,必须得把dot文件保存成UTF-8编码,可是我用C Runtime、MFC CFile、C++ iostream都只会保存成ASCII的,于是不可避免地要再多一道工序把字符编码转换一下。  从一开始我就想到了iconv。先拿来它的可执行文件,在控制台上尝试了几次,原来是要把中文的设置为gbk才行,如果是ascii或者gb_2312-80都是不行的。知道iconv确实是可以将编码转换后,就放心大胆地在程序中使用iconv库了。从公司归档库中找得到的只有1.9版的,但好在.h文件和.lib文件都有,看了一下头文件中的声明,猜猜也就是先iconv_open,然后iconv、最后iconv_close共三步操作而已。于是先把文件都读出来,然后iconv。可是死活不能把转换后的内容存放到目的缓冲区中,而源缓冲区,以及返回值,还是源数据长度和目的数据长度却都是对的,实在不得要领。这样郁闷了好久,还是不得其法,于是准备直接用iconv.exe来转换算了。  iconv.exe转换时会把转换后的结果直接在控制台输出,可以通过管道重定向到文件中,可是在程序中要得到这个结果就遇到了些挫折。首先想到的当然是CreateProcess,然后通过管道捕获输出,可是发现这新生成的进程一直不结束,我估计是哪个参数没设对,这个API的参数也太多了点,昏厥!放弃,试了试C runtime函数system,倒是可以直接像在控制台上写一个有重定向的命令行,可是在执行时,会出来两个黑的控制台窗口,这用户体验也太差了!再放弃,看了看ShellExecute这个API,但好像不能重定向。  还是转回来用iconv库吧!最后还是从网上找了一段代码,先要iconv传入几个空指针的调用,再一行一行地从源文件中读出内容,再一行一行地调用iconv,最后一行一行地写入目的文件,这样居然就行了,大汗淋漓!

迁户口,迁档案之二

迁户口,迁档案之二

  今天去关内给小丫头迁档案和户口,早上睡到8点多,很不情愿地起床,不过也比平时上班时晚了一个多小时了,昨晚睡得也不晚啊,怎么会那么困呢。洗漱完毕出门,已经过了8点半了,等328路,结果一直等到9点才勉强挤上一辆。  到了那公司,还不到10点,这出乎我原来的预料,心里顿时放松了一点。那么一个小公司,里面有个女人招呼我过去,我拿出迁户申请和商调函。被告知那些个人资料是要填好的,于是又打电话问小丫头那些东西怎么填。接着又被告知要交档案保管费,每月20元,从2007年2月交到2008年9月,还好不是很多,但我还是忘了拿钱上去,跑到楼下的招行ATM机上取了钱上去,结果那儿的财务部说他们不收现金的,但是大概看在我已经拿了几张红纸片的份上,乱糟糟地不知道从哪里找出一本开收据的本。最先招呼我的女人把档案都装入一个档案袋,贴上纸,盖了十几下章,然后找出小丫头的户口卡交给我,第一站的任务就基本完成了。  随后是要去高新派出所办迁入户口,因为不知道坐什么车,所以一下楼就打了个的。也不知道是不是绕路了,比我想像的要久。而且想不到那派出所在那么一个偏僻的地方,不过好在一进门就看到办理的地方,取号排队,开始还取错号了,大概一直排了半个小时的样子吧,才轮到我,那办理的大姐一看就说出我们公司的名字,看来我们公司在那儿的业务很多啊。没几分钟就办完了,时间都耗在坐车和排队上了。  出了派出所,看到路对面就是一个公交车始发站,看来只有转车了。这车也是绕路的,绕了好久,到了市民中心,本来想坐个391回公司的,结果等了10几分钟也没等到,失去了耐心,决定再次转车,先坐到梅林关,再爬上一个小巴,1点半差3分的时候终于赶回公司刷卡,这样就只需要报上午半天的假了。  坐下吃了块巧克力,因为早饭和中饭都没吃,饿啊!然后给小妞打电话,问她有没有吃的,她说有小面包。于是我先跑到人事服务中心,把户口卡和档案交回去,结果那管档案的mm说还缺转正定级表,我郁闷,这党员还真麻烦啊!指不准还得跑一趟关内,累啊,要是自己有车就好了!

终于借到《Lex与Yacc》了

终于借到《Lex与Yacc》了

  几个月前,就想从公司图书馆去借本《Lex与Yacc》了,可是从在线服务中可以查到确实有一本没有借出去,但到了图书馆就是找不到那本书放在什么地方了,图书馆的人说他们也没有办法找到,因为书要么就是照着编号放在书架上的,如果在指定的书架上没有,那就没办法了。我还为此去了几次图书馆,希望碰碰运气万一某一天他们整理的时候能发现那本没有找到的书,但是一次一次都失望而归。也想过自己买一本,但逛过深圳的几处大型书城,都没有找到过,从网上倒是能看到介绍,可是都是断货了,太郁闷了!  昨天觉得该去还那本《Windows技术内幕》了,虽然借了三个月,但没看几页。到图书馆一看,惊喜地发现有一本《Lex与Yacc》静静地躺在柜台面上,看来是刚刚有人还回来的,连忙抢到手中。  实在觉得这词法分析和语法分析在处理模式化文本时太有用了。说起来虽然现在在做那个劳什子一体化平台,可是我心里却一直想回去完善编辑器,简直有种生不逢时,壮志未酬的感觉。本来同事是有一种语法解析组件的,大概浏览过那代码,其实是从ruby源代码里抠出来,在某一阶段直接把语法分析树dump出来。不过不知道为什么在源代码超过8000行时,分析出来的行号总是过绕接,从头开始。我也没仔细定位过这个问题到底是哪里出了错,主要是那代码全是别人写的,而且用了一些我个人极不喜欢的处理方式,我就懒得再去查错和修正了。我宁可自己再写一个解析器,因为我知道用lex和yacc可以做到。当时简单地看过ruby的源代码,发现它的词法分析器并不是用lex生成的,并且里里有一段代码是用gperf生成的,于是以为gperf也是一种词法分析器生成器,后来自己用了gperf才明白过来,原来ruby的词法分析器是手写的,其中gperf生成的那段代码只是为了识别出其中的保留字而已。而语法分析器确实像是用yacc生成的,不过由于ruby的语法太过于魔幻,所以语法分析器似乎复杂得超出我的想像。如果我回头再去做编辑器,这个语法解析器势在必行,不关是为了解析出语法树显示出来,另外还有些用途。其中之一是,其中有一个另外的需求是将表格化的描述与脚本来回转换,如果没有可靠的语法解析器支持,这个需求要实现就实在太过困难了点。另外还有个需求,是前两天才提出来的,说是要能跳转到方法定义处,于是当然要知道方法定义的位置,而这位置当然需要事先准备好。本来还以为rdoc从源代码中提取文件时可以顺便提取出来,后来同事一说,yaml中并没有保留文件名和行号,所以还得想办法提出来。我一想这个就太不可靠了点,万一某些方法就是没有注释文档呢。所以一定要另外有个模块来提取方法定义,我当时想到了ctags。今天试了试,发现用ctags还是有些缺憾,它只能提取出方法名称,以及匹配该名称的正则表达式,而并没有行号。另外,看了看ctags的源代码,发现另外更严重的问题,ruby并没有说定义方法时def关键字和方法名一定要在同一行中,如果是不同行中,ctags就不行了,所以还是得实实在在的语法解析器出马啊!  当然,像ruby这种比较复杂的语法解析,我不需求全部自己从头开始写起,可以抄袭一部分它的代码,至少词法分析器大部分可以直接使用,而那语法解析里把BNF留下,把动作换掉, 这样虽然还是要读懂那部分代码,但总比全部自己来轻松多了,而且也可靠得多。  得稍微系统点地学习一下lex与yacc了。