首页
归档
分类
标签
软件
关于
链接
订阅
代码
类库大魔王的挖井日记
挖一口属于自己的井
All Stories
把最幸福的事都回忆一遍
昨天晚上,近12点,锁好门,准备熄灯上床,却听到手机的短信铃声响起。当时我就猜,在这么个时间,说不定是那小丫头发的,不,应该是我很肯定,一定是那小丫头发的。拿起一看,果然是小丫头,那个我曾经叫她宝宝,后来一直称呼为小乖的女人。短信的内容倒比较意外,说自己头好痛,眼睛也好痛,要爆了,却又睡不着。于是我便拨回去。 两个人断断续续,说着从我毕业工作以来的两个人之间的几乎每一件事情。睡在同一个屋子里,一起逛街,一起去欢乐谷玩,给她买眼霜和书,帮她买数码相机和笔记本,她大队培训期间出去玩让我在家里着急,买了里芯已经烂了的苹果给她……她问我她要结婚了我祝不祝福她。我短暂地沉默后,回答当然祝福了。然后她就在电话那头哭起来,我问她为什么哭,是不是他对她不好。她说没什么,他对她很好很好。还说她最对不起的人就是我,我说我没有怪你,是我自己给你这个机会让你对不起我的。而且就算真的很喜欢很喜欢一个人,也不是一定要生活在一起的。以前听小思宇说起过,陈奕讯在一个访谈节目中说的,他都已经有小孩的人了,到现在心中还是一直放不下一个人,惦记着一个人。我也可以。 我给她说起我妈妈,那是一个眼光很挑剔的中年妇女,我把众多女同事,女同学的照片拿回家给她看,基本上都是挑缺点的。小丫头就说,是不是她的脸那么圆,我妈妈也是不喜欢的。我解释说,你那种圆脸,我妈妈是很喜欢的,还说了脸圆圆的,屁股也圆圆的,这样的女孩子才好。小丫头说,那她最终也没能成为我妈妈的儿媳妇。我说,那是我妈的儿子没本事,没福气。说到很少见小丫头哭,其中的一次,是那年雪灾,到了机场没车回家,给我发短信,在机场一个人哭,我正在家里吃饭,我妈问我在跟谁发短信,我说了后,我妈还叫我回短信让小丫头不要哭了,不然不漂亮了,而我却说小丫头脸圆圆的,哭起来的样子很可爱的。 还说到,我曾经在她的照片袋里看到她和一个男生的大头贴,我心好酸好痛,当时怎么那么老实,没有趁上街的机会拉她一起去拍大头贴。她说,那个男生是yaya以前的男朋友,居然让人误会了,哈哈,印象中好像也只有这么一个男生一起拍过大头贴。后来她又说到,当时我千方百计把她介绍进公司,本来是希望能离得近一点的,想不到一下就被派到成都去了,是不是当时后悔得要死。我说,后悔倒没有,就是很痛恨这个命运,想不到在命运的面前真的一点能力都没有。真的,我不但痛恨这个命运,还痛恨着这个公司,就是它把小丫头弄到离我那么远的地方去了,便宜了以后可能成为她老公的那个小子。我问小丫头,如果她还是一直呆在深圳的话,我应该还是有机会的吧。小丫头轻轻笑笑。 小丫头说,很怀念以前在深圳的日子。呃,她只在深圳呆了不到半年。我说我也是,我很怀念她在深圳的日子。 几乎把我觉得最幸福的事情都回忆了一遍,最后我说,以后不要哭了,你哭我也会难过的,你已经不和我一起生活了,那就要在其他方面有所补偿,你担负着让我们两个人都快乐的责任。
图形程序设计续之困扰
开始做那个图形编辑程序1周多了,现在遇到了瓶颈,因为原来的设计考虑得太不全面,很多很明显的问题都没有有顾及到,结果到实际编码实现到一定程度时,发现原来的程序结构有点不行了,不够用了。 主要的矛盾在于,原本我的设计上是,每种图形,都各自响应用户操作,互相不知道其他同类的存在。而实际上这是不对的,或者说不合适的,比如连接线,在端点确定前就是要知道那个位置是否贴到某个图形上了。另一方面,当某个图形上的连接点移动时,同样得通知所有跟这连接点连着的连接线,或者是某个图形被删除时,得同时删除连接在它上面的所有连接线。 本来所有图形对象都在一个管理器进行任务分派,现在看来,至少有得有一个类,可能还是这个图形对象管理器,做更多的事情,可以查询它所管理的图形对象一些特殊的状态,还要维护图形对象间的关系,可以是一个邻接矩阵,或一个邻接链表,反正就是一个图的表示法。这些不是我现在的主要困扰,我的困扰在于,图形对象怎么来调用这些查询状态的操作。本来图形对象被那个管理器对象包含了,另一方面那些查询状态的操作得知道所有这些对象,这样的循环依赖,让我感觉不爽!
有点必要学习SQL
话说,我并不是计算机科班出身,因此很多基础的知识都是不知道的。这不,发现SQL真是有必要要好好学习一下了。最近在很多地方用到了数据库来存储东西,于是不可避免地需要写些SQL,最最基本的SELECT、INSERT、UPDATE还是会点的,不过也仅限于在单表中进行操作。 前两天发现一个可以显著提高在Sqlite3中SELECT性能的方法,那就是建索引。因为IDE需要AutoCompletion和Calltip功能,而用于这两个功能的数据都是存在一个sqlite3数据库中,该数据库目前已经有不少数据了,光是一张记录了方法的表,就有1万多条记录,从中SELECT是经常要做的操作,所以能提高点性能是很有意义的事。自从给该表建了索引后,至少感觉上非常明显,AutoCompletion几乎没有任何停顿就提示出来了,而以前的话,有个明显的停顿,虽然这个停顿的时间并不长,但已经能让人感觉出来了。这只是一点,让我觉得学习一下SQL有好处的地方,就让我尝到了莫大的甜头。还有一点就是,有不少地方的SELECT的条件,是从这次其他的SELECT中取得的数据,而我全部都是分成一条SELECT一次操作来进行的,我想,如果能把这些SELECT合并成一条语句,应该还是能再提高点运行速度吧。
图形程序设计与实现
这周开始投入环境组网绘图功能的Demo实现。说简单点,这就是一个图形编辑器,就像Visio之类的。以前也有过自己使用GDI画图形的经历,但那时更简单的一点,没有要求图形可以移动,所以实现时做的事更少些。虽然这次说是做Demo,但我为了以后能以这Demo为基础,继续实际项目的完全实现,在初期就做了不少事情,费了好些心思。 首先是程序架构上,基本上是按照实际项目的设计来做的,以后也不用做大的修改和调整。界面上会有的元素,都留出位置了。花了近2天的时候,才把主界面的框架搭好。昨天又花了1天,把输入的数据源那部分功能也差不多完成了。今天才开始实现真正的绘图功能。 这次Demo主要就是为了预研或显示绘图功能,所以这里需要投入的精力更多。项目使用MFC开发,不使用任何其他第三方的库,传统而显而易见的作法是在CView上进行绘制。本着尽量OO的原则,最先可以想到的是,每种图形元素,可以用一个独立的类来表示,而所有这些类,有一个公共的基类,在基类中声明接口。以前的设计中,我只是让每种图形类保存了各自的位置和类型信息,并实现一个绘图接口。这次我突然发现,如果把相应的响应用户操作也放到各个图形类中实现,才更合理。比如点住鼠标进行移动,这得让图形类自己决定自己该进行什么动作,像一般的矩形,就可以直接将整个矩形进行移动,像折线,则可能只是在中间的折点进行移动。于是一般说来,这些图形类应该能处理鼠标的按键按下,弹起,光标移动等事件。现在觉得这样的设计是理所当然的,可在以前,我是绝对想不到这点的,也确实曾经把这些操作都放到外面统一分类处理。而且自从知道了Loki::Factory这个模板类后,对于这种大批类的操作,我有种近乎执着的热情想让它们不被任何除了这工厂之外的其他模块知道,直至不知道它们的存在。有了这一批图形类后,就需要一个管理器来维护这些图形类实例化出来的对象。这个管理器完全将这些图形类实例的创建、销毁、任务分派等与界面(CView)隔离开来。对于界面来说,图形对象管理器可以完成所有功能。 再说代码实现方面。这次专门看了一遍GDI+的SDK,准备试用一番,嗯,不算试用,是实际用上了。MFC中使用GDI+没有任何限制,在CView的OnDraw方法中把所有图形绘制一遍即可。当然也有双缓冲以免闪烁。网上的用GDI+实现双缓冲的文章和代码都很多,但一般说来只分两种:1、标准的GDI+做法,临时创建一个Gdiplus::Bitmap,将所有内容都画到这个Bitmap上,再将这个Bitmap画到设备上去;2、GDI风格的做法,先创建一个内存DC,GDI+都向这个内存DC画内容,最后将这内存DC都BitBlt到设备上。经过我的实验,发现第1种方法的资源消耗比较大,速度感觉上似乎也慢一点,但没具体测过,没实际数据来证明。于是我换用第2种做法,网上有一个很流行的CMemDC类,使用非常方便。但等我这样实现完后,发现移动某个图形时,需要刷新整个绘图区,还是会闪烁。上网随便搜索一下,发现一个很简单的解决办法:处理WM_ERASEBKGND消息,直接返回TRUE就可以了。
初步了解google-breakpad
第一次知道google-breakpad这个东西,是一篇讲chrome使用的开源库的文章,当时也只是一带而过,心想这功能也能做成多平台的? 最近还是因为项目的需要,原本已经有一个这种实现的,是从FileZilla的2.x版本中抠出来的,不过有些时候会生成不了dump,让人觉得诧异,还有一些是生成了dump,但最后发现栈回调的信息太缺乏可参考的价值了。我估摸着,这可能跟如何使用dbghelp.dll里的函数的方式有关系,而这google-breakpad在我看来可能是当前功能实现得最好的一个了,就打算好好了解一下。 从svn里取得到的代码,解决方案是用于VC2005的,大概google内部VC都是用的2005吧,看到好些它的开源项目都是。直接用VC2008打开,自动转换版本后,也可以直接编译。主要看src\client\windows\目录下的代码就可以了,一般而言可以用到的有3个lib文件,分别是crash_generation.lib、exception_handler.lib、crash_report_sender.lib。如果用户程序只是为了能生成minidump,直接链接exception_handler.lib就可以了,crash_generation.lib已经被它包含了,而crash_report_sender.lib顾名思义是可以将文件发送到某个地方的,从代码上看,是通过http的上传功能来实现的,不过还没研究。另外还有一个GUI的演示程序,crash_generation_app.exe,可以测试除0异常,CRT函数参数无效异常以及纯虚函数调用异常。 通过阅读crash_generation_app.exe的代码可以大体上了解google-breakpad的使用方法。google-breakpad将这么一个小功能分成几部分来实现,首先,它分为服务器和客户端两部分,这两部分都可以生成minidump,但应用场景不同。用户程序出现未处理异常时,被ExceptionHandler捕获到,该模块会根据当前进程是否已连接到一个服务器,来决定由谁来生成minidump。在crash_generation_app.exe中默认是会去连接一个服务器的,所以如果服务器没有问题,则是由服务器来生成minidump的。而且服务器生成minidump不限于当前进程,它通过Event得到客户端的dump请求,通过管道进行其他数据的传递。使用C/S结构的好处是,可以尽量减少对被dump进程的影响,代价则是大大增加了代码实现的复杂性。如果没有可连接的服务器,客户端也可自己生成minidump,这部分的实现上网上的所有有关这个主题的代码,基本上都是相同的。唯一有点区别的是,网上其他的代码一般只接管了未处理异常,而google-breakpad则还可以接管CRT函数无效参数异常和纯虚函数调用异常。 在crash_generation_app.exe的实现中,使用服务器dump的方式,最后返回的结果总是说没成功,而实际是dump文件是生成了的,这应该算是个bug吧。还有个问题是,如果一开始尝试连接到服务器后,后来服务器又被关掉了,那之后的dump会全都失败,这可能是因为演示的缘故,没有仔细编写这种异常流程的处理代码吧。另外,算是小瑕疵吧,用google-breakpad默认好像是不能自定义dump文件的名字,只能指定个保存路径,最后的文件名是随机生成的uuid。 总的说来,对于有这方面需求的应用,使用google-breakpad是个不错的选择,它做了不少工作。
MinGW中使用GDI+
昨晚坚持到1点多,做了两件事:1、验证GDI+在MinGW中的使用;2、编译wxWidgets中access这个sample。 GDI+在MinGW中的使用,在网上有不少方法,但绝大多数是不行的,至少都有点小小的问题需要自己修改一下。我本来是没想过有这方面的需求的,也是因为最近想用用GDI+,就顺便想试试MinGW是否也可以。很快就搞定了,先到这里下载一个包含GDI+的头文件和库文件的包,然后把所有头文件解压出来放到MinGw的include目录下面,再把库文件放到MinGW的lib目录下面,其实我没用这个包里的libgdiplus.a文件,而是用reimp.exe重新生成了一个。网上有篇文章说,reimp.exe后面的参数是GDIPlus.dll,其实是错的,看一下reimp.exe自带的命令行参数说明就知道,人家明明是接受一个IMPLIB嘛,所以要跟GDIPlus.lib,之后会生成libgdiplus.a和gdiplus.def文件。这些文件准备好后,可以试着写个小程序编译一下,我就没自己写,直接试着用MinGW编译wxWidgets,带GDIPlus编译,中间会报两个错,错误提示很明显,只要打开那两个文件,把它报错的地方,定义类成员函数的签名的地方,不用加类名作用域就可以了。 编译access则花了我不少时间,因为其中不少时间是在等待wxWidgets库的编译。如果使用默认的编译选项,最后可能也可以得到一个可执行程序,但在运行时会弹出消息框说要定义一个什么wxUSE_ACCESSIBLITY之类的宏。这时可以修改一下access的makefile,在编译命令行中加入这个宏定义。再编译时,可能到最后一步是说某些符号链接找不到。我当时的第一反应是,编译wxWidgets时没有定义这个宏,于是修改src/msw/setup.h中的定义,将这个宏的值设为1,再编译,到最后也是说找不到一些符号链接,这才意识到是没有链接相应的库,还是修改makefile,加上-loleacc,给wxWidgets和access的makefile都要加,就可以正常编译过了,运行access也可以正常工作了。
昨晚遭遇小偷入室
早上醒来,习惯性地找床头的iPhone看时间,居然没找到,很奇怪地起床,找挎包,心想昨天记得把手机拿出来了的啊,结果连挎包也不见了,越发奇怪,等到发现卧室门打开着,才开始有点焦虑,走到客厅一看,挎包被丢在靠近门口鞋架的旁边,里面的东西已经被翻过了,钱包里面大约有1千的现金已经不翼而飞了。这时我才确认,昨天晚上有贼入室了,这才稍微有点后怕,晚上有人进来我居然什么都不知道,万幸的是,只是丢了点钱和一个iPhone,至少连T43都没丢,T200也在,PSP,NDSL都在,连一起放在挎包里的Nano都还在,除了这些,人身也是没损失。 情绪理所当然地比较差,但也不知道到底是什么心情,没有恐惧,没有愤怒,没有后悔,没有惋惜,只想躺床上睡一觉。大约的损失总共是5000RMB,却没有一点心疼的感觉,对金钱的态度自己都觉得有点不可理喻。想要钱,却不在乎钱。 这该死的国家,该死的社会,我诅咒这个世界,却对那个小偷什么想法都没有,连骂几句,憎恨一下的念头一丁点儿都没有。 还是得靠自己,拥有了强大的力量,才能保护好自己和对自己来说重要的人或东西。
可以自动提交dump分析记录了
今天花了近一天的时间,重新写了一遍自动分析mini dump然后将分析结果提交到wiki上的程序。通过这次实践,也确认了我原先的想法是可行的,内嵌一个IE,然后通过它暴露的COM接口,进行一些基本的操作,主要有遍历已有元素,填充TextArea,提交。只是发现这些操作,全都不是阻塞的,所以具体应用的时候还是得留心一下。 晚上加班,看了一下一个公司的人写的ppt,介绍Erlang的,看得让我觉得有点不舒服。按我的理解来看这ppt,似乎他的意思是公司目前使用C/C++来开发电信类软件,而且有那么多的问题,而Erlang从语言的机制上就提供了不少的保障机制,可以写出更快更稳的程序来。让我感觉他在鼓吹这就是银弹。就我以为,写这个ppt的目的就不明确,或者说就算明确了,也是动机不纯,我们应该立足于眼前,如何提高公司开发人员的设计和编码水平,而不是考虑着换一种语言就妄图可以解决一堆问题。 不过总的说来,我看了《Erlang程序设计》中的前面一两章后,就觉得这是我真的需要的一种东西,也许它在保证并发上,或者FP编码风格的处理上并不完美和彻底,但就目前看来,它应该是比较适合我的需求的一个选择。
原来一直都理解错了
嗯,一直以来都以为UTF-8和Unicode是一类的,今天才明白过来,UTF-8确实明明是多字节一类的才对啊,我的理解能力实在是太差了,唉! 不过今天倒是也知道了,如果只是要在ANSI、Unicode、UTF-8之间进行转换,使用两个Win32 API就可以全部搞定了,不需要用什么iconv和ICU了。总是觉得微软做的东西易用性真的很好,通用软件产品很适合普通用户使用,而那些开发工具、库、API对于开发者来说,也很好用啊! 唉,我也就只用玩一下这些容易的东西了。
« Prev
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
Next »
发现
→
imported from CSDN (124)
Film & ACG (15)
Water (170)
Shareware (151)
Software (140)
Plugin Framework (28)
lookfor (36)
CPPOOPGPXP (87)
Lua,Script (51)
Be Old (15)
Job (185)
mm (48)
Emulator (3)
Execise Outdoor (13)
gfw (10)
Reading (20)
Driving (16)
Mobile (15)
wxWidgets (29)
WIND (14)
PSP NDS (2)
CodingStudio (44)
Cryptography (2)
Editor,IDE (6)
TeX (1)
Life (84)
Technic (6)
Qt (29)
SNS (35)
Ninayan (35)
GUI Framework (1)
KarenMeu (1)
Kindle (3)
Coding (16)
Startup (6)
network (16)
Go (10)
idea (1)
os (2)
iOS (1)
Cloud (1)
device (2)
embed (6)
gochess (1)
Router (3)
blog (7)
cmake (2)
Network (1)