首页
归档
分类
标签
软件
关于
链接
订阅
代码
类库大魔王的挖井日记
挖一口属于自己的井
All Stories
代码合得有点问题
用了wxScintilla,我一直试图让其中用到的Scintilla代码保持跟官方CVS中的同步。现在发现,还是合得有问题了,功能没合进来,但是光是看代码,我也不知道到底哪里出错了。具体的现象是,现在官方的Scintilla是已经能直接支持多块选择了,昨天试了试我的程序是不行的。不过这个问题暂时倒不要紧,可以放到以后去修改。 看到SciTE开始有实验性的支持使用Lua脚本实现lexer了,不过接口还没有稳定下来。不过我猜这个特性可能不会合到Scintilla里面去,而且即使合进去了,我暂时也没有这个需求。 自从前些天看到TextMate的Bundles的介绍,以及Zen Coding的介绍,心里一直蠢蠢欲动!VS在有VA强大的智能提示的帮助下,或许可以不用这种方式的支持。但对于已经习惯于UNIX使用文化的人来说,这种自动代码生成方式是很符合他们的使用习惯的,而且同时又能极大地提升编码效率。我就开始琢磨着能不能也实现一下。 Zen Coding的效果看来,主要适用于HTML这种从SGML衍生而来的标识语言,这主要是它的语法,以及它的生成代码上的限制,所以如果不是这方面的应用,可以暂时不管它。 而TextMate的Bundles看起来就很让人心动了,以前只是听说过却没有直观地体验过,所以感触不深,前些天看了一些评论和操作视频以及manual,冲击太大了。当然这种机制在Windows平台上命令行工具并不流行,脚本解释器又不默认安装的环境下,可能不如Linux/Unix/Mac上那么突出,但如果能做成对少数几种工具、脚本语言的支持,也是很有诱惑力的。 大概想了下,如果要实现这套机制,要修改一下Scintilla中对Tab和Back Tab的实现。目前Scintilla中的Tab有两种不同的行为,如果选中整行或多行了,则会对选中行进行缩进,其他情况则是插入空格或制表符。在Bundles中或者说Tab Triggers中,Tab又多了两种行为,一个是缩写扩展,如果同时有多个扩展使用相同的缩写,则要显示AutoCompletion下拉框,另一个是缩写扩展后光标自动跳转。所以我的想法是,要在Scintilla原来的两种行为中增加缩写扩展的行为,并在内部保存一个状态,表示缩写扩展后,所有的Tab操作不再进行默认的缩进或插入空格(制表符),而是在这些时候都给个通知,让宿主程序自己处理这个操作。而宿主程序在适合的时候再发个消息给Scintilla重置那个状态,以便Scintilla又退回原来的Tab处理方式。 算了,不说了,先搞定调试器,再来看这个吧!
Windows下编译器内存分配释放性能对比(续)
今天搞到了C++Builder2010,里面的bcc是6.21版本,相比bcc5.5,也是经过4个版本升级了,隐约记得在某个版本中,把CRT中的内存管理部分改用FastMM了,所以它的表现应该有所不同。 经过与前一次基本相同的测试,得到结果。从该数据中可以看到,6.21版本提升了多线程情况下的小块内存操作的性能,在1024字节以下的malloc测试中,表现优于所有其他的编译器!但在1M字节以上的测试中,还不如bcc5.5版本。而且,它的new操作耗时比malloc操作耗时多很多,大约是半倍到一倍的样子。在单线程小块内存的操作中,表现可以用技惊四座来形容,直逼OpenWatcom,甚至偶尔略有超越。但是在大块内存操作中,反而都不如原来BCC5.5。 详细测试用可执行程序与测试结果可以点击这里下载。
Windows下编译器内存分配释放性能对比
前些天有人在群里说起测试malloc和HeapAlloc的效率,后来又在豆瓣上有人讨论起大块内存的策略问题,于是我决心再稍微仔细地测试一下各个编译器在这方面的表现。 首先,我选取了OpenWatcom 1.8、Digital Mars 8.51、Borland 5.5、MinGW GCC 4.4.0、MSVC 2008、Intel 11.0.061一共6种编译器,除了Intel C++,其他的编译器都可以在网上下载并免费使用。 然后写了一个非常简单的小程序,分别对1字节,1000字节,1024字节,1M字节,10M字节和50M字节进行重复的分配和释放,前三种大小重复15000000次,后三种大小重复150000次。为什么前三种的重复次数是后三种的100倍呢?因为测试过程中我发现,后三种的耗时在某些编译器中太长了,等不及了! 接着,使用所有这些编译器编译出4种不同CRT配置的可执行程序。分别是单线程静态链接,单线程动态链接,多线程静态链接和多线程动态链接。我都是使用bjam的默认参数编译的,其中Intel编译器不能生成单线程静态链接的可执行程序,但我想影响很小,也就不再追究。 最后就是运行每个程序,我的机器配置是Thinkpad T43,1.86GHz的P4m,1.5G内存,Windows XP SP3。每种跑10次,计平均时间,可以得到一些有趣的结果。从不同的维度观察这些数据,可以得到不同的结论。 先比较不同编译器间的差别。从实际上看,MinGW和Intel都是使用了msvcrt,只不过默认情况下MinGW使用的是6.0版本,Intel则使用当前安装的VC的最高版本的CRT库,我的机器上是9.0,所以总的说来这三者的差别应该不大。 在1字节的大小时,Digital Mars表现平稳而出色都在2s出头,而VC、MinGW和Intel都超过3s,OpenWatcom跟VC类似,但在单线程静态链接时就爆发了,只需要1s出头,而Borland在单线程中都只用1s多。 1000字节的测试基本与1字节的情况相同,但Digital Mars的耗时却飚升了近1倍! 而1024字节时,VC、MinGW和Intel的耗时又比1000字节时多了近1倍,看来这1000和1024之间有个阀值影响msvcrt使用不同的分配策略。 在1M、10M和50M字节的测试中,三个测试的数据差别不大,但与前三者的测试数据比较可以看出,OpenWatcom和DigitalMars的表现平稳,变化不大,但使用msvcrt的三者则耗时飚升,大约是前二者的400~500倍,是1024字节的200~250倍,这个差别比较大! 总的说来,Borland C++只有在单线程,小块内存分配时的表现还不错,这在DOS时代是好的,但进入了Windows时代,程序开发纷纷往多线程,大内存占用的方向发展时,它几乎没有进步。Open Watcom是受分配内存块大小影响最小的,几乎没有变化,而且总体上它在各个横向比较中性能是最好的。Digital Mars略次于Open Watcom,但它在单线程或多线程,静态或动态链接中几乎没有差别,估计最终使用的是同一个CRT库。VC、MinGW和Intel的表现基本相同,除了单线程静态链接小块内存分配外,其他情况都略好于Borland C++,所以可以看到Intel编译器的优化是集中在指令流的调整上,而对内存这块是忽略了。...
不错的励志歌曲——Trouble Is A Friend
澳洲甜美歌声,我听了Lenka的12首歌,最后的结论是,只要听这一首就够了!歌词如下: trouble will find you no matter where you go oh oh 麻烦会找到你 不管你往哪里走 哦哦…… no matter if you're fast no matter if you're slow oh oh 不管你是赶路 不管你想停留 哦哦……...
买了个豆浆机
因为前些天小师妹在网上跟我说,喝豆浆养肠胃。嗯,我肠胃不好已经很久了,我爸妈的肠胃也不好,所以我觉得买个豆浆机很有必要。 今天去4S店拿行驶证和发票什么的,昨晚聊天太晚了,今天老是走神,真危险呀。看来开车是个很耗体能和精力的事情,以后在前夜一定要保证精、气、神的良好状态! 吃过中饭去一百,先看到美的,看了一会儿,抬头看到九阳的柜台,于是直奔过去,买了个很便宜的,不能打冷饮的,呃,反正现在只是想喝豆浆而已!
也晒下我的Firefox扩展
看到有人晒他用的Firefox扩展,想想自从我走出学校以来,就开始用Firefox,已经4个年头了,也晒下我用的扩展,Firefox如果不用扩展,还真是连IE都不如呢! Adblock Plus,这个几乎是所有装了Firefox后都会装的扩展吧,我当年是过了好久才反应过来,用Firefox确实很少弹出各种广告窗口哦,全靠它了。 接上,有个同事后来跟我说,有个小NoScipt的东东,很霸道,我试了,果然把每个页面上的一堆脚本都禁了,确实从事实上到心理上,都更安全了。 AutoPager这是个国人做的扩展,可以自动把下一页的内容接到本页下方,造福了我这种懒人,看论坛可以一滚到底,当然我最开心的是用它来在线看小说,几百章也可以拼成一页,好壮观! AutoProxy翻墙利器,不想花钱用VPN,只能用Tor之类的免费方案,但又难忍它的龟速,当然要把白名单里的网站剔除掉了。 Echofon似乎是个不翻墙也可以用twitter的方案,功能一般吧,有时候还自动登录不了,界面也不好看,还不能自动缩短网址。 FireGesture好像是Firefox中最流行的鼠标手势扩展吧,其中有一个版本用着很不顺手,好在过了没多久升级后,又顺手起来了。现在用鼠标手势操作浏览器大概是非菜鸟的必备技能吧。 接着是一组扩展合用,为了让Firefox的界面像Chrome那样,主要是先装个第三方Theme叫Chromifox Extreme,然后是扩展Chromifox Companion,这样可以让Firefox的Tab,工具栏,地址栏的背景色,位置等跟Chrome比较想像,然后是装Hide Caption和Hide Menubar把标题栏和菜单栏都隐藏起来,这样至少跟Chrome有九分像了! 比较有意思的是Google Redesigned扩展,可以把Google Reader、GMail、Google Calendar的默认界面替换掉,嗯,我就是个换肤论者,就是想试试不同的界面!还有个Integrated Gmail,可以在Gmail的web界面中又同时显示当前账号的Google Reader以及Google Calendar内容,对于gfan来说也是值得试用的,一个入口多种服务嘛! Weave Sync可以将书签、浏览历史、密码和Tab信息保存到远程服务器上,不过我是没什么大用,因为我基本上只在我自己的机器上用,而且Firefox也被我用命令行的方式重新指定了用户数据的目录,所以直接备份也不麻烦。 除了这些,还有什么QuickDrag呀,Tab Mix Plus呀,UnMht呀,CoolPreviews呀,Coral IE Tab呀,Flagfox呀,Shorten URL这些扩展,平时装着也是装着,用得不多,但偶然想到时若没有这些功能,又会觉得有点儿不舒服,姑且留着吧!
上牌记
买车已经一个多月了,还没有上牌,如果早知道买个车有这么多烦人的事情,我真的得考虑一下这个付出是否值得,本来想有个车,是为了方便,结果到目前为止,有的更多的是,则是烦心! 今天去绍兴上牌,起了个大早,嗯,辞职以来还没这么早过!匆匆忙忙吃过早饭,赶到4S店里。等了一会儿,售车的小姐说了相关事项后,我就先出去加油了,毕竟到绍兴有不近的路呢。结果加完油出来,明明我横插着已经过马路一半了,有辆车硬是从我前面飞过,结果擦到了!那车都没看清,就直接跑掉了。我就下了车看了看,心疼加恼火啊,一新车,连牌都没上,已经有两处被擦坏了!如果有一天让我遇到那个人,我tmd撞死他! 后来也没听到什么说话,上牌的车队一声不吭就开走了,我还以为不是我要跟的队,傻乎乎地等了一会儿,就打电话给带队的人,结果说就是那队车,郁闷了,我连路都不认识,只好沿着大路追上去,一直没追上,倒是自长训后,第一次飚快车,当然其实没上100码的。 带队的人结果只好在一个要拐弯的地方等着,他却开得更快,大概是为了追前面已经去的车队吧。不过这也有好处,至少让我明白一个事,车子在高速的情况下,确实很难刹住的。路上看到一队大客车,同一款同一色,也是去上牌的,真壮观呀! 好不容易到了车管所(?),好多车排除,现在买车的人果然多了,唉!想起那些人,一方面叫嚣着要劝人们出门多坐公交,少开私家车,一方面却仍做着那些不经过大脑的事情,就说我们地的公交车吧,已经稀疏地半个小时一趟了,还会不时地有翘班的,除了这些,有很大杀伤力的是,有个严禁超载的规定,一辆中巴能坐几个人呀,不到20吧,往往在那等几个小时也上不了车,这大冷的天,或者以后大热的天,不逼着人省吃俭用自己买车吗! 再扯回话题,好多车,慢慢排进去,几分钟才会移一个车位,过了不知道多久多久,终于到了车检了,我还真有点慌如果让我自己过那条道的话,呵呵。车检过了后,绕到后面,然后就是无休止的等待,排了个号,前面还有37个人,到12点时,前面还有18个人。出去走了快半个小时的路,找到一个地方吃快餐,好咸的大排!然后又走回去,要到1点半才开始下午的,无所事事地等了半个小时,开了门又无所事事地不知道等了多少小时,好不容易认证好手续。 最后是最重要的选号,嗯,这里我又算是被忽悠了!原来这里是分两种的,但是没人跟我说过!一种是八选一,一种是个性号码。八选一的话,当场可以拿到牌,我不知道啊,只是乐呵呵地报了个号,结果就成个性号码了,还得再等三四天他们寄过来!这其实也没多少个性,本来还想选2216,就跟家里的电话号码一样,结果2215和2217都有,就唯独没2216,唉!选好号码后,带队的人问临时牌照到期没有,是否需要再打印一张,一张5块钱!我艹,怎么以前就不知道有这回事,以前的临时牌照都是4S店里卖我车的那个女人跟我打的,我连忙打回电话去问,居然说需要再打一张,我说那你再帮我打一张不就得了。她说,一辆车只能打三张,我以前已经领完了!这明显是他们的问题啊,当时就是他们说等几天就可以在上虞上牌的,我才一拖再拖,搞得现在连3张临时牌照都用完了,而且我事先还不知道有这规矩!我实在是比较愤怒,以后再买车,绝对不会再去那家店了! 另外,我还得强烈谴责一下那些电视剧和小说,上面怎么全都是直接跑到4S店里,交了钱后什么手续都办完了的,完全是欺骗观众和读者啊! 就当吃一堑,长一智了。这辆起码车,就当是学费了。下一个目标:3到5年后,换个60到80万级别的车。
慢工出细活
我决定,不再盲目赶进度了! 一直以来我都处于一种奇怪的紧张赶进度的状态,每个月都想着能在当月或下月底前release一个可用的版本出来,于是为了达到这个目的,又由于实现中的各种未预期的状况出现,一项又一项的特性被我临时决定砍掉,或拖延到以后版本中实现。 所谓慢工出细活,现在我决定,不这么着了!对于那些基本特性,还是要花时间仔细实现的。所谓基本特性,就是别的大部分同类都有这些特性,假如没有这些特性,用户就会感觉到不习惯甚至诧异。这些基本特性有着这样的定位:在第一个版本应该实现大部分,而且以后版本的维护工作量很小。 对于要缩短每个版本的开发周期,我觉得砍掉特性或安排特性在不同版本实现,是必然可以采用的策略。而只有那种本产品特有的,有极高技术难度的,或单纯为了推广策略而需要分步推出的特性,才可以这样做。 嗯,今天要实现中断构建过程和在文件中查找替换的功能,希望不会有太多困难。
支持自动编码检测与转换
大清早的,被老妈叫起,驱车去4公里外的集市吃早餐。要了一客小笼包子,一碗馄饨,说起来从上大学开始这八九年来,还真很少吃得到这样的早餐。上学的时候嫌贵了,工作了之后就一般只在公司食堂里吃,周末虽然在家,但都睡过去了。偶尔为之,真是享受啊! 昨天突然想起,我的编辑器只能打开ANSI格式的文件,如果是Unicode,UTF-8之类的文件,打开是一片空白的,于是想改一下吧,打开时检测一下文件头部的BOM,用iconv转换一下再显示到编辑器。本来以为这将是很顺便的一件事情,从网上下载了Windows下可用的iconv库和头文件,最后却无奈地发现一个诡异的事情。原本至少ANSI格式的文件中的中文是可以正常显示出来的,如果用了iconv库,无论有没有进行编码转换,中文就全部变乱码了,而且显示乱码后,Scintilla就会报断言失败,然后整个程序就崩溃了。最后我不得不相信,这应该是iconv与wxWidgets或Scintilla配合有问题,至于到底是什么问题,我就不深究了。 没了iconv,于是我只好转投ICU门下了。还有点比较头痛,却又让我觉得解脱的一点是,我C++程序将是用MinGW编译的,而ICU当前的4.2.0.1版本曾经尝试了很久,都只能让VC编译通过,MinGW无奈地败下阵来。这就说明,我这编码转换的功能不能通过C++实现了,也省得我再费心思去琢磨到底把这个功能放在哪里实现了。Luaforge上有个叫ICU4Lua的项目,可以在Lua中使用ICU,这个库我以前也编译过,拿出来试了试,非常简单易用,只好把读取和保存文件的功能也用Lua实现成插件了。
« 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)