All Stories

UNICODE与Scintilla合用的问题

UNICODE与Scintilla合用的问题

  今天做另外一个工具的一点维护工作,需求是通过用户输入的宏名,宏值,类名,函数名以有函数返回值,工具要能自动到指定的文件中找到指定的位置,自动插入生成代码。本来这个需求是上个版本就已经实现了的,今天只是对需求有略微一点修改。可是最大的问题是,今天发现以前实现的这个根本不能用啊,文件是能找到,可是位置却是错的,根本毫无联系。  调试了很久,实现过程是首先利用MSR的greta来找到参考标记,取得标记的位置,然后插入生成的代码。一开始怀疑是取得标记的位置不对,其实冷静地想想,这种可能性几乎不存在。不过我还是傻傻地加入代码,看标记位置取回的字符串内容,毫无疑问,肯定是对的。接着怀疑是Scintilla的插入方法有问题,同样事后想想,这种可能性也微乎其微。不过我也不死心地,加入代码,看该位置的Scintilla文本,果然已经是不正常的内容了。  正在束手无策之时,突然不知怎的,灵光一闪,可能是因为看到其他一个项目中使用多字节编码的greta,觉得可能是这里引起的问题。greta在匹配文本时,在unicode情况下,一个中文字符和一个英文字符都是一占一个长度,而此时Scintilla还是以多字节方式处理,一个中文字符占两个长度,所以greta算出的位置对scintilla来说并不能对应上。想通了这一点,立即将工程编译选项切换到多字节方式编译,果然就正常了。  这次遇到这个问题,也能为以后实现相关需求,或者解决类似问题,提供了极大的参考价值。

培训计划

培训计划

  老大叫我整理一份项目组内成员的C++相关内容的培训计划。我还是兴冲冲地去弄的,不过基本上是参考我自身的情况制订的,内容方面不是我比较熟悉的,就是我比较欠缺但又在工作中比较需要的。  主要分了8大类,分别是C++对象模型、C++模板、STL、Boost、面向对象程序设计、Windows API、MFC、COM。每一类,都又划出好几个培训课程,我还根据自己所了解的,分别给每一类都备注了参考资料,每一类的的参考资料大多只是两三本经典书籍,比如COM类的,我就写了《COM本质论》和《深入解析ATL》,而Windows API类我就写了《Windows程序设计》和《Windows核心编程》,等等。  等我把这份列表发给老大,老大又转给更大的老大,更大的老大则回复说,内容太多了,要分轻重缓急。我觉得很有道理,这样的培训是很耗费资源的,当然应该拣最有用的来。不过他列出的前3位是Windows API、MFC和COM,对于我来说,就有点兴味索然了。虽然这些方面我也远远说不上精通,甚至连熟悉都不够,但我自以为,应付工作上的要求是够了。比COM举例来说,我虽然排斥COM,但必须用地方还是会用的,我会调用COM服务器,同时我也写过COM组件,我觉得自己够了。  既然不能把这份列表作为组内的培训计划,我看了看,觉得依照这些列出的参考资料,也可作为我自己的增强计划。这8类我都有所了解,在实际工作中也都或多或少地有所运用,但我不禁要考虑,学到什么程度算是够?  我个人倾向于学习和使用一些比较通用的技术,比如STL、Boost之类平台无关的知识我就很有兴趣,而COM则是有点深恶痛绝的感觉,MFC稍微好过一点,不过也不是很喜欢。这不是我研究了这些东西后主动有了喜恶观念,而是不知不觉在一个比较长时间内养成的兴趣倾向,直到后来自己总结的时候才发现这个规律。  其实我根本没多少想法,要尝到什么程度,目前而言,我只好给自己暂订个目标,STL、Boost、C++模板和对象模型,以及面向对象程序开发,是能学多少算多少,而其他的,则是够用就行。

使用wxWidgets一天有感

使用wxWidgets一天有感

  幸亏有Code::blocks和CodeLite两个的源代码可以参考,可以省事不少,不过还是发现,要像现在用MFC一样的比较熟练地使用wxWidgets仍需要先阅读一些基本的资料,当然wxWidgets的manual也是必不可少的。  学习一种新的GUI框架的使用方式,关键还是在于了解并掌握它的消息处理机制。通常见到的GUI系统都是消息驱动的,所有所有的编程框架都不可避免地要有一套自己的消息处理机制,而且这套机制的设计好处,直接影响到整个框架的运行效率和使用效率。  总的说来,我感觉目前wxWidgets已经有点庞杂,好处是有些问题可以有多种解决方案,坏处是增加了学习成本以及降低运行效率。总觉得它不但最终生成的可执行文件体积大,而且运行效率太低。不过似乎用gcc编译出来的代码,运行效率也不如用VC编译出来的。假设能用Intel编译器来编译,是不是运行效率能更高呢?  现在用wxWidgets来写程序,还有个比较麻烦的问题是,跟用MFC开发相比,缺少一个好用的开发工具。以目前凡事都追求效率的情况来讲,写程序早已不是随便找个文本编辑器就能写代码的时代了,不光要有基本的文本编辑能力,其他自动完成、重构、提示、引用跳转、向导等等,无不影响着程序员的心情,以及开发效率。从这方面讲,目前已经没有哪个环境能跟VC+MFC比了。用vc也能写wxWidgets程序,但跟开发MFC程序相比,它缺了各种向导,比如Property视图,可以直接为各种系统消息、命令ID生成对应的函数声明,还有常用类派生的虚函数实现。  不过,总算起步了!

在家包饺子

在家包饺子

  本来计划是明天的,因为冬至要吃饺子,结果F说明天要加班,于是只要提前到了今天。  那几个家伙也够懒的,能睡那么久,不过也让我有点羡慕,因为我到了早上7、8点的时候,就开始睡不着了。  结果等cm0同学过来的时候,已经1点了,然后跑去超市买菜。安排的是中饭吃炒菜,晚饭吃饺子。买了130多的东西,当然不全是吃的,还有cm0买的什么卫生纸之类的东西。F去超市旁的KFC买了鸡米花、圣代、薯条、蛋塔,因为实在不知道我们什么时候才能吃上中饭。  中饭的菜基本上是我弄的,也跟平时我自己弄的一样,一个肉丝、蒲瓜、金针茹、香干丝混炒,一个白灼基围虾。味道自我感觉还是满意的。吃完就已经4点半了。  吃过中饭,就打了一会儿升级,我的手气不是一般的差,不知道那个跟我搭档的cm0有什么感想,哈哈,反正我们一直都是打2,没升过级,而对方已经打到7了。  7点时,开始准备晚饭,即饺子。我没有动手,因为我实在没有经验,就看着他们三个包,份量挺大的,满满一大盆的馅,厚厚的两叠皮。最后吃剩下15个左右,没办法了,只好浪费了,唉,可惜!  另外还剩下鸡汤和鸡肉没动呢!

最近脾气比较坏

最近脾气比较坏

  被另外一个同事说了两次了,说我最近越来越酷了。今天我就问哪里酷了,他说竟然敢当面顶撞王总了。我心中冷笑,多从来不认为公司里这种领导对下属可以指手划脚,颐指气使,我从来只觉得领导也不过是个打工的,只不过与其他下属的工作内容不一样,他的职责不是领导人,而是协调各种资源,包括人力。  不过最近脾气比较坏倒是真的,我完全是被搞烦了,我也顾不上那么多了,气不过我就要反驳。今天早上的站立式会议时,我还对老大出言不逊了,我就直言他们对COM的过度热衷和盲目崇拜。  后来老大找我沟通,说我是不是对现在的项目很有情绪,我说是不爽,而且感觉付出和回报不成比例,付出得太多,回报得太少。  下午在回顾今天发的版本发现的问题后,质量部的人又在那里摆了很久龙门阵,知道我们想要撤出,便在那里说了一通项目的前景,个人的前景,画了好大好大一个饼,呵!

好大一块巧克力

好大一块巧克力

  大牛上周从俄罗斯出差回来,今天给了我好大一块巧克力,哈哈!  单从包装外来观察,这块巧克力厚就不止1cm吧,宽不止10cm,长不止20cm。包装上全是俄文,我也找不出哪里写了具体的体积规格参数,手头也没有尺子可以量一下,反正就是很大一块。中午猫猫还说,大牛把最大的一块给我了,给她的就没有我的大,哈哈,想起这个就觉得开心!  我们公司的人去国外出差,习俗就是带当地的巧克力回来给同事朋友们尝尝。以前吃过那位cm0同学不知道谁给她的德国巧克力,薄薄的一盒,里面是一小条一小条,味道比小卖部的德芙好多了。只可惜我是没什么机会出国出差了,除非赚了钱自己去旅游去。  其实我很喜欢吃巧克力的,只是太容易长胖了,哈哈!

解决构建时间超长的问题

解决构建时间超长的问题

  今天终于搞明白为什么昨天构建我的项目要2个小时了,原来是内存耗完了!  本来一直没这种问题的,也就昨天突然发现,我的项目集成构建一次,最多的时候要206分钟,瀑布汗!当时还以为是中间的哪个环节出问题了被阻塞在那里了,看了下进程状态都是好的,主要的时间都花在doxygen生成文档上了。但看看doxygen也是正常的,有条不紊地dot。  其实昨天就已经搞好了,因为当时发现本来2GB的物理内存,又设了2GB的虚拟内存,可是看看整个系统的内存使用量居然也是3GB多。关了一票的没用的进程,包括普通应用程序和系统服务,发现又变快了。  今天重启了系统,同样关掉那些没用的服务和应用程序,再看CruiseControl,终于恢复正常了,15分钟就能完整地执行完一次构建!  唉,服务器资源还是有限啊!

先把框架搭起来再说

先把框架搭起来再说

  一直沉迷于网络小说,完全属于玩物丧志的类型!今天无聊完,郁闷完,打开VS来,决定先把框架搭起来再说。  总的说来,这是一个需要用外部脚本和配置文件协同扩展才能让业务逻辑正常运行的系统,而C++部分纯粹是为了实现用脚本比较困难的核心功能。虽然想了很久很久了,但一直迟迟没动手,玩物丧志是主因。  另一个不太重要的借口是,没找到好用的开发工具。微软的一个很好的实践是dogfood,很早以前看《微软的秘密》一书时就知道这个了,前些天听那微软的专家交流时,又看到这个,觉得很有趣。像Code::Blocks和CodeLite都是典型的dogfood,使用自己来做为开发工具。而我目前还处于一片空白的阶段,被Visual Assist X惯坏了的我又受不了其他工具的弱智,于是一直停在那里。今天想通了,就用VS来作开发环境好了,先用VC编译一个debug的wxWidgets,要retail版本时,就写好makefile,用gcc来编译。  这次恢复系统后,只装了个VS2008,这一方面可以让我不至于为众多的选择而分心,同时也减少多版本并存而可能出现的各种奇怪问题。前两天把原本只能用VS2005打开的WIND工程尝试着用VS2008打开,居然没崩溃,高兴之余把用WTL封装了的Scintilla代码也精简了一把,删掉了几千行代码,这下应该更不会崩溃了吧!

用wiki记录开发文档

用wiki记录开发文档

  前天,公司请MS的人来做交流,我也去听了一下,虽然只听懂了20%~30%,还有有翻译,尽管翻译的水平不咋的,连蒙带猜的大致上也能搞明白他在讲什么。其中让我印象最深感触最深的一个实践,是用wiki记录开发文档,其他人也可以修改文档,有新人加入时,就可以通过wiki进行学习,我深以为然。  昨天,老大提出,我们项目组也要组建公共知识库,也包括开发文档。有个同事提出,他倾向于使用Word文档来进行记录这些内容。这不禁让我开始思考,用wiki和用Word来记录开发文档,各有什么优缺点。  大体说来,我是倾向于用wiki的,因为我觉得wiki的形式更能鼓励人们不断跟着代码变化而自发地更新文档,并且wiki一般自带版本管理功能,使用更方便,另外一方面,开发文档并不需要多丰富多样的格式,有简单的文本和插图一般够用了,而Word文档拥有的其他功能,可算是累赘了,比如要比较两个版本的差异,就相对要麻烦一点点。  说到底,我其实最看重的是wiki形式的约束下,人们会更多地完善文档,我们项目组目前的一大问题是,并没有多少文档,代码中偶尔有几行注释就算是全部的文档了。假如我们也像产品开发人员那样有非常详细的从SRS到HLD,再到LLD,那用wiki和用Word文档,或者其他什么记录形式,根本没有区别。