你的字典里有多少元素?

“字典”或者说“哈希表”大家都会用,这真是一个好东西,只要创建了之后就可以不断的丢东西进去,添加删除都是O(1)操作,那叫一个快字了得。不过这里我要再次引用Alan Perlis的名言:“Lisp programmers know the value of everything but the cost of nothing.”,目的是想提醒做事“不要忘记背后的代价”。 上图引自Wikipedia中“Hash table”条目,描述了最常用的“哈希表”实现方式之一,也是

逆泛型执行器

话说微信公众账号上的第一期有奖征答活动发布至今已有两周时间,不过参与人数寥寥,是太难,还是奖品不够吸引人?大家要多参与,我们才能长期互动嘛。现在我就对第一期的题目“逆泛型执行器”进行简单讲解吧,其实这题很简单,以后类似难度的题目可能会放在“快速问答”环节中。话说第一期的快速问答还在进行之中,大家加油。 参考解答 所谓“逆泛型”,即我们希望可以在一个泛型操作中,只对特定的类型组合进行响应。例如: public class TicksToDateTimeCaller {

.NET程序性能的基本要领

说起Roslyn大家肯定都已经有所耳闻了,这是下一代C#和VB.NET的编译器实现。Roslyn使用纯托管代码开发,但性能超过之前使用C++编写的原生实现。Bill Chiles是Roslyn的PM(程序经理,Program Manager),他最近写了一篇文章叫做《Essential Performance Facts and .NET Framework Tips》,其中总结了几条经验,目前是个CodePlex上的PDF文件,以后可能会发布在MSDN上。 他在文章里谈到

在香港生活的初步感受

好久没有更新博客了,主要是生活产生了一些变化。我这人比较没出息,生活稳定的时候,不论是工作和学习都会有条不紊,但一旦有所动荡,则就会心神不宁,啥事都做不进去,效率也一落千丈,比如Coursera上的基本课程也拉下了。这段时间比较重大的变化有两点: 与女友领证了。 在香港工作了。 这两件事其实是相关的。相信不少同学都知道我当年去IBM深圳的主要原因之一,就是看重这是个和JPMC的合作项目,两年后有机会可以去香港。可惜两年期满,这计划却黄了,幸好我还是为自己争取到了这样的

比较下中国大陆和香港之间的个税差异

一直听说中国大陆个税税率之高,但一直没有跟哪儿作过比较,最近听说香港的税率很低,因此也想具体比较一下到底会差多少。单从数字上看,两者简直天差地远。例如,同样是累进税率,大陆从月入8K开始的部分就要缴纳20%的税率,超过38.5K则是30%,而香港最高也就只有17%。当然,比如香港租房之贵也遥遥领先于大陆一线城市,但房租亦可作为征税前的减免。正因为如此复杂,我们还是需要进行详细的计算才能有直观的概念,这里我就来尝试一下。这里以一对夫妻为例,但只计算其中一人的薪资,以传说中阿里P

抓取InfoQ内容的calibre脚本

两个礼拜前我公开了一个抓取今年MSDN Magazine内容的calibre脚本,这次则是针对InfoQ的。最近用Kindle Paperwhite看书一发不可收拾,自然想要更好地利用这个设备。InfoQ是一个难得的高质量站点,可惜它的RSS只输出摘要,甚至只有前十条内容,让人感到十分不方便。但这显然难不住calibre这个电子书管理神器和伟大的程序员,于是我这段时间又断断续续地编写了InfoQ站点内容的抓取脚本,各个方面细节感觉修饰地都还算不错,特此公布。至于这个脚本该怎么

使用calibre抓取2013年的MSDN Magazine

前段时间入手Kindle Paperwhite,这已经是我第三个Kindle设备了。想当年我花了四五千块钱,在亚马逊美国站上跟着老美预定,可谓是全世界第一批Kindle DX(大屏幕的那款阅读器)用户,不过用着用着后来还是去玩平板了。这次Kindle Paperwhite出了国行设备,才849元,顿觉实在是太便宜了,立即下单,第二天就拿到了这台设备。 有了设备自然要用,除了官方书店里买的书以外,第三方的内容自然也必不可少,毕竟目前国内的Kindle电子书还太少(尤其是计算机

防止装箱落实到底,只做一半也是失败

.NET提供struct类型,正确使用可以减少对象数量,从而降低GC压力,提高性能。不过有时候我会发现,某些同学有这方面的意识,但是有时候一疏忽一偷懒,就没有得到相应的效果了。这里举一个真实的例子:假设我们要将一对int作为字典的键,用于映射到某些数据,那么你会怎么做?当然我们可以直接使用Tuple<int, int>,但这样就可能产生大量的对象。于是我们打算使用自定义的值类型: private struct MyKey { private readon

为什么我不喜欢Go语言式的接口(即Structural Typing)

所谓Go语言式的接口,就是不用显示声明类型T实现了接口I,只要类型T的公开方法完全满足接口I的要求,就可以把类型T的对象用在需要接口I的地方。这种做法的学名叫做Structural Typing,有人也把它看作是一种静态的Duck Typing。除了Go的接口以外,类似的东西也有比如Scala里的Traits等等。有人觉得这个特性很好,但我个人并不喜欢这种做法,所以在这里谈谈它的缺点。当然这跟动态语言静态语言的讨论类似,不能简单粗暴的下一个“好”或“不好”的结论。 那么就从

为什么我认为goroutine和channel是把别的平台上类库的功能内置在语言里

这几天看了《Go语言编程》这本书,感觉一般,具体可见这篇书评。书评里面我提到“Go语言的goroutine和channel其实是把别的语言/平台上类库的功能内置到语言里”,这句话当然单单这么说出来是没什么价值的,于是我也就趁热把它说得再详细一些。我的看法简而言之是:由goroutine和channel所带来的主要编程范式、设计思路等等,其实基本都可以在其他一些平台中配合特定的类库来实现。 我们知道,操作系统的最小调度单元是“线程”,要执行任何一段代码,都必须落实到“线程”上