博客园_winter-cn

字符编码那点事儿

2012-01-27T15:42:00Z

那时，天下人的口音、言语，都是一样。他们往东边迁移的时候，在示拿地遇见一片平原，就住在那里。他们彼此商量说：“来吧！我们要作砖，把砖烧透了。”他们就拿砖当石头，又拿石漆当灰泥。他们说：“来吧！我们要建造一座城和一座塔，塔顶通天，为要传扬我们的名，免得我们分散在全地上。”耶和华降临，要看看世人所建造的城和塔。耶和华说：“看哪！他们成为一样的人民，都是一样的言语，如今既作起这事来，以后他们所要作的事，就没有不成就的了。我们下去，在那里变乱他们的口音，使他们的言语彼此不通。”于是，耶和华使他们从那里分散在全地上；他们就停工不造那城了。因为耶和华在那里变乱天下人的言语，使众人分散在全地上，所以那城名叫巴别。

——《创世记》

字符、字符集、字符编码

先说字符，字符大家都很清楚了，英文叫做character，通常的简写叫做char，字符加上一种字体（Font），就可以得到字型（Glyph），字型就是我们眼前所见之物了。

字符用来在计算机领域表示语言和文字，世间有无穷多字符，如果沟通的双方要互相明白，就必须使用相同的字符集。字符集会规定一种或者几种用计算机字节表示字符的方法，这个方法就叫做字符编码。

ASCII

ASCII恐怕是最最著名的字符集了,至今为止还有人将ASCII误认为是计算机中表示字符的方法的代称，在任何编程系统中都会问"如何获取某一字符的ASCII码"。ASCII中共有127个字符，主要包含大小写英文字母、标点和一些控制符号。ASCII既是字符集，又是字符编码，ASCII的每个字符对应着0-127中的一个整数，这个整数称为字符的ASCII码。例如，字符'a'的ASCII码是97。

ASCII在计算机发展初期是非常NB的，这个时期主要是英语国家在使用计算机，而对当时的少数非英语国家用户而言，英语根本不成为门槛，ASCII编码可以放在一个Byte之中，这通常是计算机最小的空间单位。

哦对了，ASCII后来被国际标准化组织搞成了ISO/IEC 646，算是有了正式名分。

ASCII兼容编码

因为ASCII对于英语之外的文字完全没有考虑，所以显然没法满足全球人民日益增长的字符使用需要，而由于ASCII编码被广泛使用，所以又没法完完全全地重新发明一套新的字符集和编码方式。

注意到ASCII只占用了0-127，但是一个字节其实可以表示256个数字，于是128到255或者说-128到-1这些值被一些人开始盯上了。于是一些ASCII兼容编码开始出现了，其中我朝人民最为熟悉的就是GB2312了,unicode的UTF8编码方式也是ASCII兼容的，这些后文再详细分说。

ASCII兼容是向下兼容，即某种编码方式不需要经过任何转换接受任何以ASCII编码的文本为合法的，并且字符与当做ASCII编码时是完全一致的。

几乎所有的ASCII兼容编码方式都是变长编码，因为每个ASCII字符只占一个字节。

GB2312、GBK、GB18030

ASCII字符集里面不包括中文，那么显然这对于我国人民的感情来说是难以接受的，于是党和各级人民政府当然不会允许这种事情发生。在倪光南院士等人的关怀下，1980年具有独立自主知识产权的GB2312横空出世了。

1995年，在社会主义伟大旗帜下，有关部门组织一些专家对GB2312做了一些扩充，形成了GBK编码，也就是GB13000标准。

2000年，为了满足人民日益增长的字符使用需要，我国又制定了GB18030标准。

GB系列的编码还有一个称呼叫做区位码。

ANSI

关于ANSI这种说不上是编码方式还是字符集的充满狗血故事的概念，还真是不太好讲。好吧首先ANSI的意思是American National Standards Institute，美国国家标准学会，嗯，但是很遗憾美国国家标准学会从来没有制定过这么一个标准，也不可能制定出来（好吧很快你就可以知道为什么了）。

最初这个东西如何出现，现在已经不可考证，但是毫无疑问至今windows的记事本保存选项里面仍然有这么一个叫做ANSI的选项。为什么说ANSI其实并不是一种字符集，也不是一个编码呢？因为实际上ANSI会随着操作系统的区域和语言设置而变化！当你将非unicode默认语言选成中文时，这个选项保存出来的文件赫然就是GB2312！对的！我认为ANSI这个词乃是米帝国主义亡我之心不死，妄图将伟大社会主义字符编码标准GB2312划入米国之手啊！

好吧，认真地说， ANSI这个概念颇为脑残，它的实际意思是遵循本地化设置的编码方式，但是却不伦不类地扯上了米国国家标准学会。

Unicode

讲字符编码一定不能漏了Unicode了，现在Unicode确实不负uni之名，是最有机会达成大统一重造巴别塔的一个字符集。Unicode的最新版本是6.0。

Unicode是一个字符集而不是一个编码方式，Unicode中每个字符对应一个code point(中译为码点，觉得不喜欢这个翻译) 。code point是一个0x00000到0x10FFFF之间的正整数。因此Unicode的字符都被记为U+XXXX，XXXX就是code point的16进制表示了。

Unicode还把code point分成17个code plane，其中主要使用的是0,1,2,3四个平面，也就是U+0000-U+FFFF，U+10000-U+1FFFF，U+20000-U+2FFFF，U+30000-U+3FFFF这四个code point的集合。

Unicode本身是抽象的，它发布的时候会带一个参考字型但是实际上它把字型的决定权交给了字体，所以code point就是字符的唯一标识了。

UTF

unicode本身并非编码方式，所以unicode需要编码方式配合，常见的unicode编码方式就是UTF。UTF-X的数字X就表示最少用几个bit来表示一个字符。

常见的表示方式有UTF-8、UTF-16、UTF-32、UTF-7、UTF-24......

Unicode的 code plane共只有17个，所以UTF-32已经是定长编码了，它能表示的范围是0x00000000到0xFFFFFFFF，这显然远远超过现在Unicode的code point范围，所以短期内可以认为UTF-32是定长编码。定长编码的好处是，获取一个字符串的长度可以直接根据它占用的内存计算出，所以UTF家族中只有UTF-32可以享受到了。

UTF-8是最常用的UTF编码，特别地，它还是ASCII兼容的。

值得注意的是，这些编码里面，UTF-16使用甚广，因为unicode1.0发布的时候， UTF-16还可以认为是定长编码，于是一些倒霉孩子比如Java就把UTF-16当成自己的字符串在内存中存储使用的编码，于是搞出来Char类型其实并不是每个表示一个字符，而是表示一个UTF-16 code unit这样的人间惨剧。

UTF-8对英文文本来说是非常合适的，但是中文每个文字要占三个字节，相比之下，UTF-16中的中文则是只占2个字节，所以当你的系统对存储容量或者网络流量敏感的时候，应该根据你的文本主要组成方式选择UTF恰当的编码。

大端和小端

对于UTF-16、UTF-32这种东西而言，还有一个很现实的问题，它们的code unit都是一个正整数，而计算机系统的最小单位是字节，字节表示正整数是有高位低位顺序之分的，于是我们就有了大端小端的事情，相信用过window记事本的同学都有印象，里面有两个选项unicode big endian和unicode，实际上这里unicode指的就是UTF-16编码。

BOM

BOM又叫做Byte Order Mark，起因是我们的unicode里面规定了一个神奇的字符零宽空格U+FEFF，这个字符好啊，它明明是个字符，还显示不出来，于是一些程序员大爷想出了个nb的办法，约定所有的UTF数据流，都先吐出一个U+FEFF来，反正又不会显示出来，根据这个U+FEFF的表示方法，就可以判断数据流所使用的UTF编码了。比如说，收到三个字节EF BB BF的话，就可以断定来的编码是UTF-8了。

这个NB办法后来也被推广到其它编码上（嗯，比如GB就不行，跟BOM冲突，打开记事本输入"联通"，然后保存为ANSI，再打开看看），也渐渐有了称呼叫做BOM。但是很遗憾，不少人不懂规矩，不会在数据源前面加BOM，于是天下间的文本，又被分为了有BOM和无BOM两种......

UCS

很多人说Unicode的标准是ISO16406，实际上这话不对，UCS才是。这中间有一段非常蛋疼的历史，unicode和ucs是分别由两个不同组织编写和发布的不同标准，但是因为二者在很早些时候就达成共识，一直紧密合作，始终默契地保持两份标准的一致，所以其实可以认为Unicode就是UCS了。

然而跟Unicode不同，UCS本身还规定了编码方式，主要有两种：UCS-2和UCS-4，这里的2和4表示最少用几个byte来表示一个字符。UCS-4也是定长编码，它跟UTF-32完全一致，所以二者只是理论上是两种编码而已。

值得注意的是，UCS-2与UTF-16是不完全一致的，UCS-2也是一种定长编码，code point超出0xFFFF的字符怎么办呢？UCS-2......它表示不了这些字符！

ISO-8859

实际上，制定了自己的编码标准的不仅仅是我们伟大的天朝，欧州国家也制定了一些自己的编码规范，它们都是针对特定地区的编码，不同语言使用不同字符集，所以互相之间不能混排，简单地说，就是跟GB2312一路货色，这些东西也就是前面提到过的ANSI编码了。

ISO-8859是一组规范，而不是一个规范，ISO-8859-1大家一定经常在各处见到，它表示西欧字符集。ISO-8859家族现在一共有15个，序号是从1排到16，除了12之外，关于为啥没有12有些不同说法，又说原本是要给加入塞尔特语族的Latin-7，也有说是留给印度天体梵文的，总之就是因为一些奇怪的原因跳过去了。

很遗憾我朝大佬对于ISO毫无兴趣（也许ISO9001是例外？），因此GB始终是GB，没能加入ISO当中，不过GB基本可以认为是跟ISO-8859同一体系的一种编码。

结语

对于字符和编码的这点事，我自己蛋疼了很久，才渐渐理解了其中错综复杂的关系，这篇文章信息量不大，不过是个感性理解，希望对一些人会有帮助吧。

本文链接

C#字符串与享元（Flyweight）模式

2012-01-20T18:09:00Z

写这个文章，主要是因为网上对C#字符串和享元模式的误解比较多。

Flyweight模式

先说这名字，fly呢，就是苍蝇，没错这里面不是飞的意思，是苍蝇的意思，weight大家都知道，就是重量，苍蝇的重量，就是非常非常轻的意思。所以Flyweight模式就是处理非常非常轻量级对象的一个东西。

Flyweight的目标是解决大量细粒度对象的内存消耗问题，当然，巧妇难为无米之炊，任何模式和手法都不能凭空造出内存来，所以享元模式针对的情况是这些细粒度对象的中数据有重复的情况。

Flyweight的做法是，把对象的状态（通常用属性表示），分成两个部分，一部分是内部状态，另一部分是外部状态。内部状态是不易重复的（或者说必要的），外部状态是易重复的。所以，Flyweight把外部状态提取出来共享，这样就一定程度解决了内存占用问题。

C#中的字符串不是Flyweight模式

在网上常常可以看到一个说法，说C#中的字符串使用了Flyweight模式，开门见山地说，这个说法是错误的。

错在哪里呢？按照上文的介绍，错就错在字符串它没有所谓的“内部状态”。

通常讲字符串是享元的原因就是以下代码：

string a = "Hello World";
Console.WriteLine(Object.ReferenceEquals(a, "Hello World")); //True

当使用字符串直接量的时候，不论你写了多少个"Hello World"，最终内存里面只有一个字符串对象。

运行时创建的字符串并不在此列，可以使些手段，强制在内存里面产生新的字符串。

string a = "Hello World";
Console.WriteLine(Object.ReferenceEquals(a, new String("Hello World".ToCharArray()))); //False

因为我们强行调用了new，所以这个字符串跟内存中的直接量"Hello World"对应的对象不是同一个。

有趣的是，C#还允许强制把一个字符串加入到（如果已经有了，就只是找出来）字符串池里面。

string a = "Hello World";
string b = String.Intern(new String("Hello World".ToCharArray()));
Console.WriteLine(Object.ReferenceEquals(a,b) );

或者

string a = String.Intern(new String("Hello World".ToCharArray()));
string b = String.Intern(new String("Hello World".ToCharArray()));
Console.WriteLine(Object.ReferenceEquals(a,b) );

前面提到了，这个行为跟Flyweight使用的内部状态和外部状态不同，是两个对象实实在在就是同一个对象。

C#中的字符串与Flyweight模式

好吧，前面说了不少，C#中的字符串不是Flyweight模式，但是是不是就意味着C#里面字符串跟Flyweight没有关系呢？

当然不是，否则我写这么一篇文章岂不是太蛋疼了……

字符串池和Intern方法简直是实现Flyweight的神器啊！

考虑我们有某一类对象，可能会创建几百万个，对象里面恰巧有这么一个属性叫做颜色，它在对象构造的时候随机产生，颜色用的是rgb色，用rgb24来表示，于是颜色字符串类似#ccc这样子。

代码写起来就像下面的样子：

class Element
    {
	static Random rnd = new Random();
	static char[] table;
	static Element() 
	{
	    table = "0123456789abcdef".ToCharArray();
	}

	public string color;
	public Element()
	{
	    color = "" + table[rnd.Next() % 16] + table[rnd.Next() % 16] + table[rnd.Next() % 16];
	}
    }

接下来我们创建3千万个对象看看如何

Element[] eles = new Element[30000000];
	    for (var i = 0; i < 30000000; i++)
	    {
		eles[i] = new Element();
	    }

从任务管理器看到一大块内存被吃掉了

接下来我们使用String.Intern来实现Flyweight：

class Element
    {
	static Random rnd = new Random();
	static char[] table;
	static Element() 
	{
	    table = "0123456789abcdef".ToCharArray();
	}

	public string color;
	public Element()
	{
	    color = String.Intern("" + table[rnd.Next() % 16] + table[rnd.Next() % 16] + table[rnd.Next() % 16]);
	}
    }

同样来看看运行结果：

可以看到内存占用量的明显变化。

因为字符串对象的不可更改性质，使用了String.Intern之后，我们完全看不出前后color的区别，也就是说，修改前后的Element类是完全等效的，但是Flyweight为我们节约了大量的内存。

更多思考

这个典型的使用flyweight场景为我们揭示了享元外部状态的特征：像字符串一样不可更改的对象。GoF原书的例子中的字型对象Glyph也是如此。

String.Intern这种对象池的方式实现flyweight也值得借鉴，我们可以考虑自己设计flyweight的外部状态对象时使用类似的方式。

本文链接

语法分析算法LR(1)基础教程（上）

2011-07-19T19:26:00Z

讨厌英文的同学，请点我碰碰运气
不小心乱玩后悔了的话，请再碰碰运气，说不定会恢复

基本概念

首先解释一下基本概念

词法分析和语法分析：编译或者解释一门语言，必经两个步骤：词法分析和语法分析，词法分析就是把源代码的字符流变成计算机可理解的词汇：token，语法分析就是把token流变成一颗结构化的语法树，以便后面的程序去翻译或者分析。比如，假如计算机要想识别整数四则运算，词法分析器那么就要认识整数、加减乘除四种运算符号，以及左右括号这些token，而要根据运算符的结合性，把四则运算构建成语法树。

3 + 4 × 5

最后得到的语法树可能长成下面的样子

AdditiveExpression:

AdditiveExpression

MultipleExpression:

Integer:3

"+"

MultipleExpression:

Integer:4

"×"

Integer:5

上面这颗树用编程语言中的数据结构表达出来，就是比较容易被计算机理解和处理的了。（设计模式中的Interpreter模式，就是省略前面的步骤直接使用这种结构的）

词法分析可以简单地用正则表达式来完成，而本文则专门讲一种语法分析的经典算法：LR(1)

定义语法——BNF/EBNF

上面我们提到了四则运算，不过我们没有严格定义四则运算到底是什么，比如，有没有括号、用×还是*来表示乘法，但是计算机语言需要一个非常严谨的定义方式，现在广泛使用的就是BNF及其扩展EBNF。如我们以以下方式定义带括号四则运算：

其中Expression、AdditiveExpression、MultipleExpression 、PrimaryExpression、Integer我们成为Symbol(语法符号，C++链接器报的错误里面说找不到符号，就是这个词)，词法分析产生的每一个token也同时是Symbol，如果一个Symbol可以由若干个Symbol组成，那么称为non-terminal symbol（非终结符），否则称terminal symbol，最后生成语法树以后，terminal symbol就是所有的叶子节点。

因为对BNF的一些批评，后来出现了EBNF,它是BNF的扩展版本。

Expression ::= AdditiveExpression

AdditiveExpression ::= AdditiveExpression "+" MultipleExpression , AdditiveExpression "-" MultipleExpression , MultipleExpression

MultipleExpression ::= MultipleExpression "×" PrimaryExpression , MultipleExpression "÷" PrimaryExpression , PrimaryExpression

PrimaryExpression ::= "(" Expression ")" , Integer

在现在大多数语言规范中，都在使用BNF/EBNF或者与之非常接近的方法来描述语法。

LL与LR

常见的语法分析算法有LL和LR。

LL的第一个L表示from Left to right，第二个L表示Left most推导。

LR的第一个L和LL的第一个L含义相同，第二个R表示Right most推导。

在通常的描述中，后面还有一个括号里面的数字如，LL(0)、LL(1)、LL(4)、LR(0)、LR(1)这样，括号里面的数字表示用于决策所需的后续token数。

LR(1)状态机构建

LR(1)分析从外部看起来，每次接受一个字符，最后接收程序终结符时，内部刚好形成一颗语法树。

在内部，每当我们接受一个Symbol之后，我们就需要做一个决定：是把新的Symbol跟原有的Symbol立即合并成更高级的Symbol，还是把新的Symbol暂放呢？

在LR(1)中，有两个术语：reduce(归约)和shift(移入)。规约就是把已经读入的低级Symbol组合成高级Symbol，如Integer "x" Integer 可以reduce成MultipleExpression

仍然以上面的 3 + 4 × 5 为例，当我们接受3的时候，实际上3已经是一个完整的PrimaryExpression了,而进一步，一个PrimaryExpression也是MultipleExpression，我们可以一直将3归约到一个完整的Expression

Expression:

AdditiveExpression:

MultipleExpression:

PrimaryExpression:

Integer:3

但是我们此时不应当直接reduce到Expression，这是一个错误的语法树结构。

考虑以下两种情况：

3 + 4 × 5，在读入×时，

此时 3 + 4显然不应该被reduce

3 × 4 + 5，在读入+时

此时 3 × 4 显然应该被reduce

为了正确处理以上的问题，我们要构建一个状态机来指导LR(1)运算，何时reduce，何时shift。

由BNF我们可以得到的语法规则，以四则运算为例，最终我们想要的是一个Expression，即我们的语法树最终根节点是Expression 。

我们认为输入的token序列最终会形成一个Expression，那么考虑一个问题，状态机的最初状态0，能够接受哪些Symbol的shift呢？

第一个考虑到，状态机可以接受Expression这个Symbol,这将导致我们进入最终状态。

此外因为有语法规则Expression ::= AdditiveExpression，状态0还能接受AdditiveExpression

又因为有语法规则AdditiveExpression ::= MultipleExpression "+" MultipleExpression , MultipleExpression "-" MultipleExpression , MultipleExpression

状态0还能接受MultipleExpression

……

从这个分析过程不难看出，状态0可以接受所有Expression，以及所有能生成Expression的规则的第一个Symbol，并按此规则递归。

接下来我们要关心迁移问题了，毫无疑问接受Expression这个Symbol以后，直接进入最终状态，然而对于其它情况，如接受了一个MultipleExpression ，则会产生更多可能性，我们把AdditiveExpression ::= MultipleExpression "+" MultipleExpression , MultipleExpression "-" MultipleExpression , MultipleExpression看成3条规则，把所有的规则全都拆分出来.

每一条规则都将会形成若干状态迁移规则：

Expression ::= AdditiveExpression

● AdditiveExpression

AdditiveExpression ●

AdditiveExpression ::= AdditiveExpression "+" MultipleExpression , AdditiveExpression "-" MultipleExpression , MultipleExpression

● AdditiveExpression "+" MultipleExpression

AdditiveExpression ● "+" MultipleExpression

AdditiveExpression "+" ● MultipleExpression

AdditiveExpression "+" MultipleExpression ●

● AdditiveExpression "-" MultipleExpression

AdditiveExpression ● "-" MultipleExpression

AdditiveExpression "-" ● MultipleExpression

AdditiveExpression "-" MultipleExpression ●

● MultipleExpression

MultipleExpression ●

MultipleExpression ::= MultipleExpression "×" PrimaryExpression , MultipleExpression "÷" PrimaryExpression , PrimaryExpression

● MultipleExpression "×" PrimaryExpression

MultipleExpression ● "×" PrimaryExpression

MultipleExpression "×" ● PrimaryExpression

MultipleExpression "×" PrimaryExpression ●

● MultipleExpression "÷" PrimaryExpression

MultipleExpression ● "÷" PrimaryExpression

MultipleExpression "÷" ● PrimaryExpression

MultipleExpression "÷" PrimaryExpression ●

● PrimaryExpression

PrimaryExpression ●

PrimaryExpression ::= "(" Expression ")" , Integer

● "(" Expression ")"

"(" ● Expression ")"

"(" Expression ● ")"

"(" Expression ")" ●

● Integer

Integer ●

显而易见，我们可以总结出下面两条规律：

所有以●结尾的状态，操作就是规约,其它状态操作就是移入。
假如当前状态● 后是一个非终结符X，那么所有能规约到X的规则中以●开头的状态迁移规则也适用于当前状态。

我们现在可以认为● Expression是初始状态，Expression ● 是结束状态，根据规则2，可以得到以下状态迁移适用当前状态

● AdditiveExpression

● AdditiveExpression "+" MultipleExpression

● AdditiveExpression "-" MultipleExpression

● MultipleExpression

● MultipleExpression "×" PrimaryExpression

● MultipleExpression "÷" PrimaryExpression

● PrimaryExpression

● "(" Expression ")"

● Integer

同样开头的迁移规则必须归并，实际上，第一次我们可以得到JSON表示的以下状态结构(我们用JS程序员最喜欢的$表示reduce)

{

AdditiveExpression:{

"+": {MultipleExpression:{$:"AdditiveExpression"}},

"-": {MultipleExpression:{$:"AdditiveExpression"}},

$: "Expression"

MultipleExpression:{

"×": {PrimaryExpression:{$:"MultipleExpression"}},

"÷": {PrimaryExpression:{$:"MultipleExpression"}},

$: "AdditiveExpression"

PrimaryExpression:{$:"MultipleExpression"},

"(":{Expression:{")":{$:"PrimaryExpression"}}},

Integer:{$:"PrimaryExpression"}

}

注意，这个状态迁移关系仅仅是分析了第一个状态后的结果，要想得到完整地状态机，还要对所有后续状态递归地应用规则2。这将可能产生无限循环，为了避免这种情况，我们应该对每个状态做hash,然后把循环的情况直接指向之前的结果。

做完这些之后，我们就得到了一个完整的LR(1)状态机。

下篇：LR(1)分析过程

本文链接

驳“面向对象的基本特性多态”

2011-05-03T13:57:00Z

在网上常常能看到文章讲面向对象的三大基本特征"继承"、"封装"、"多态"，我以为这是坊间流传的最不靠谱的一个说法。本文先谈谈其中讲到的一个特性：多态。多态是一个跟面向对象完全正交的概念，两者之间可以说没有任何必然联系。当然口说无凭，下面是我经过很长时间查找到的一些来源比较可靠的资料对多态的说法。

最早可查证的关于多态的说法是一篇叫做 Fundamental Concepts in Programming Languages的论文，文中对多态的讨论主要是用于实现运算符的重载版本选择，文中把多态分为两种： ad-hoc多态和参数多态，ad-hoc多态即指系统根据上下文自己决定如何选择运算符的行为，比如各种原生的运算符都在此列。参数多态则是根据参数类型选择。文中对参数多态的解释则是用了一个颇为"函数式"的例子，根据传入的函数类型参数的函数签名来决定返回值类型。

1985年左右的一篇论文On Understanding Types, Data Abstraction, and Polymorphis则详细地论述总结了多态性的概念，文中给出了多态的分类：

polymorphism(多态)

|-universal

| |- parametric

| \- inclusion

\-ad-hoc

|- overloading

\- coercio

这篇文章对多态的论述比较系统，网上也有pdf版本，有兴趣的朋友可以详细阅读。(inclusion多态听起来比较陌生，但是其实它的另一个名称是subtype Polymorphism,这也是唯一一种跟面向对象相关的多态)

从上面的发展可以看出，多态是一个差不多跟面向对象同时（60年代）诞生的编程概念，有自己独立的体系结构，并且这个概念非常广泛地用于很多种编程语言的设计当中。

关于面向对象跟多态的关系，下面一段话用来解释非常恰当（来自The C++ programming language），

Since both(wintercn注：根据上下文指template和abstract class) allow an algorithm to be expressed once and applied to a variety of types, people sometimes refer to both as polymorphic.

意思是：因为template和abstract class两种机制都能允许一个算法表达一次而用在多种不同类型当中，所以人们把两种都称作多态。后文还讲到abstract class提供的是运行时多态，template提供的是编译时多态。（有趣的是，连面向对象的代表性语言之一C++本身都涉及到了一种跟面向对象毫无关系的多态类型。）

所以事实上，多态并非面向对象的私产，更不是什么面向对象的基本特征，多态和面向对象的关系是：面向对象中的抽象类，提供了一种运行时多态的实现方式。

本文链接

面试时算法题的解答思路

2011-02-28T19:44:00Z

面试中纯粹考算法的问题一般是让很多程序员朋友痛恨的，这里分享下我对于解答算法题的一些思路和技巧。

一般关于算法的文章，都是从经典算法讲起，一种一种算法介绍，见得算法多了，自然就有了感悟，但如此学习花费的时间和精力却是过于巨大，也不适合在博客里面交流。这一篇文，却是专门讲快捷思路的，很多人面对算法题的时候几乎是脑子里一片空白，这一篇文章讲的就是从题目下手，把毫无思路的题目打开一个缺口的几种常见技巧。

（一）由简至繁

事实上，很多问题确实是很难在第一时间内得到正确的思路的，这时候可以尝试一种由简至繁的思路。首先把问题规模缩小到非常容易解答的地步。

[题目]有足够量的2分、5分、1分硬币，请问凑齐1元钱有多少种方法？

此题乍看上去，只会觉得完全无法入手，但是按照由简至繁的思路，我们可以先考虑极端简单的情况，假如把问题规模缩小成:有足够量的1分硬币，请问凑齐1分钱有多少种方法？毫无疑问，答案是1。

得到这一答案之后，我们可以略微扩大问题的规模：有足够量的1分硬币，凑齐2分钱有多少种方法？凑齐n分钱有多少种方法？答案仍然是1

接下来，我们可以从另一个角度来扩大问题，有足够量的1分硬币和2分硬币，凑齐n分钱有多少种方法？这时我们手里已经有了有足够量的1分硬币，凑齐任意多钱都只有1种方法，那么只用1分钱凑齐n-2分钱，有1种方法，只用1分钱凑齐n-4分钱，有1种方法，只用1分钱凑齐n-6分钱，有1种方法......

而凑齐这些n-2、n-4、n-6这些钱数，各自补上2分钱，会产生一种新的凑齐n分钱的方法，这些方法的总数+1，就是用1分硬币和2分硬币，凑齐n分钱的方法数了。

在面试时，立刻采用这种思路是一种非常有益的尝试，解决小规模问题可以让你更加熟悉问题，并且慢慢发现问题的特性，最重要的是给你的面试官正面的信号——立即动手分析问题比皱眉冥思苦想看起来好得多。

对于此题而言，我们可以很快发现问题的规模有两个维度：用a1-ak种硬币和凑齐n分钱，所以我们可以记做P(k,n)。当我们发现递归公式 P(k,n) = P(k-1,n - ak) + P(k-1,n - 2*ak) + P(k-1,n - 3*ak) ... ... 时，这个问题已经是迎刃而解了

通常由简至繁的思路，用来解决动态规划问题是非常有效的，当积累了一定量简单问题的解的时候，往往通向更高一层问题的答案已经摆在眼前了。

（二）一分为二

另一种思路，就是把问题一刀斩下，把问题分为两半，变成两个与原来问题同构的问题，能把问题一分为2，就能再一分为4，就能再一分为8，直到分成我们容易解决的问题。当尝试这种思路时，其实只需要考虑两个问题：1.一分为二以后，问题是否被简化了？ 2.根据一分为二的两个问题的解，能否方便地得出整个问题的解？

[题目]将一个数组排序。

这个经典算法肯定所有人都熟悉的不能再熟悉了，不过若是从头开始思考这个问题，倒也不是所有人都能想出几种经典的排序算法之一的，这里仅仅是用来做例子说明一分为二的思路的应用。

最简单的一分为二，就是将数组分成两半，分别排序。对于两个有序数组，我们有办法将它合并成一个有序数组，所以这个一分为二的思路是可行的，同样对于已经分成两半的数组，我们还可以将这个数组分作两半，直到我们分好的数组仅有1个元素，1个元素的数组天然就是有序的。不难看出，按这种思路我们得出的是经典数组排序算法中的“归并排序”。

还有另一种一分为二的思路，考虑到自然将数组分成两半合并起来比较复杂，我们可以考虑将数组按照大于和小于某个元素分成两半，这样只要分别解决就可以直接连接成一个有序数组了，同样这个问题也是能够再次一分为二。按照这个思路，则可以得出经典数组排序算法中的“快速排序”。

（三）化虚为实

这种思路针对的是浮点数有关的特殊问题，因为无论是穷举还是二分，对于浮点数相关的计算问题（尤其是计算几何）都难以启效，所以化虚为实，指的是把有点"虚"的浮点数，用整数来替代。具体做法是，把题目中给出的一些浮点数（不限于浮点数，我们不关心其具体大小的整数也可以）排序，然后用浮点数的序号代替本身来思考问题，等到具体计算时再替换回来。

[题目]已知n个边水平竖直的矩形（用四元组[x1,y1,x2,y2]表示），求它们的总共覆盖面积。

因为坐标可能出现浮点数，所以此题看起来十分繁复（可以实践上面由简至繁和一分为二的思路都基本无效），略一思考，矩形的覆盖关系其实只跟矩形坐标的大小有关，所以我们尝试思考将矩形的所有x值排序，然后用序号代替具体竖直，y值亦然，于是我们得到所有矩形其实处于一个2nx2n的区块当中，这样我们用最简单的穷举办法，可以计算出每一个1x1的格子是否被覆盖住了。至此，只要我们计算面积的时候，把格子的真实长宽换算回来，就已经得到题目的答案了。

本文是某天在QQ群里讨论面试时的算法问题时想到要写的，以上三种思路，是我平时遇到算法问题的快速思考方向，并非万灵药方，若是不能生效，就要静下心来慢慢思考观察了，考虑到面试的时候基本不会遇到高难度算法题，这几种技巧的命中率应该不会太低，共享给大家，希望有所帮助。

本文链接

CSS3:transform与transition背后的数学原理

2010-12-28T16:20:00Z

(很多同学看到大段的数学公式就会发昏，我以人格担保，这里面的数学公式简单的不能再简单了......)

transform的原理是计算机图形学中的2D矩阵变换，

在开始之前，首先来复习下一个简单的线性代数知识：矩阵与向量乘法。太复的用不到，只需要3维向量与3x3矩阵的乘积：

接下来我们来说说transform跟矩阵乘法的关系，我们的任何一个html元素渲染完成后可以得到一张位图，把这张位图上所有的点都做一次矩阵运算，将得到一张的新的位图，这就是transform的基本含义。

首先来看最简单的transform，translate。我们都知道tansform:translate(tx,ty);的基本含义是将一个元素的显示位置平移tx,ty。在矩阵变换中，translate体现为下面的矩阵运算：

tansform:scale(sx,sy);将一个元素拉伸或者压缩指定的倍数，它对应的矩阵变换是：

transform:rotate(a)将一个元素旋转角度a，它对应的矩阵变换是：

transform:skew(ax,ay)将一个元素研x向和y向倾斜角度ax和ay，它对应的矩阵变换是：

transform:matrix(a,b,c,d,e,f)则是完整的矩阵变换，把这张位图上所有的点都做一次矩阵乘法，得到的新位图

transition涉及到的则是另一个数学概念：贝塞尔插值。

transition的变换函数有 linear ease ease-in ease-out ease-in-out几种，通常我们尝试使用时能感觉到它们之间稍有不同。

实际上，它们是使用了不同的参数进行三次贝塞尔插值计算的结果。所以我们先来复习一下贝塞尔插值：

一个量（可以是任何矢量或者标量）从一个值到变化到另一个值，如果我们希望它按照一定时间平滑地过渡，就必须要对它进行插值。

最基本的情况，我们认为这个变化是按照时间均匀进行的，这个时候，我们称其为线性插值。而实际上，线性插值不大能满足我们的需要，因此数学上出现了很多其它的插值算法，其中贝塞尔插值法是非常典型的一种。它根据一些变换中的控制点来决定值与时间的关系。

K次贝塞尔插值算法需要k+1个控制点，最简单的一次贝塞尔插值就是线性插值，将时间表示为0到1的区间，一次贝塞尔插值公式是：

二次贝塞尔插值有3个控制点，相当于对P0和P1，P1和P2分别做贝塞尔插值，再对结果做一次贝塞尔插值计算

三次贝塞尔插值则是两次二次贝塞尔插值的结果在做一次贝塞尔插值：

回到我们的transition，我们要用到的就是三次贝塞尔插值算法了。

把时间认为是0,1区间，待变换属性也认为是0,1区间，那么所有的控制函数都是三次贝塞尔函数：

ease [0, 0] [0.25, 0.1] [0.25, 1.0] [1.0,1.0]

linear [0, 0] [0.0, 0.0] [1.0, 1.0] [1.0,1.0]

ease-in [0, 0] [0.42, 0] [1.0, 1.0] [1.0,1.0]

ease-out [0, 0] [0, 0] [0.58, 1.0] [1.0,1.0]

ease-in-out [0, 0] [0.42, 0] [0.58, 1.0] [1.0,1.0]

cubic-bezier(x1,y1,x2,y2) [0, 0] [x1, y1] [x2, y2] [1.0,1.0]

最后附上各函数图，请自行辨认：

附上 transition演示: /Files/winter-cn/transition.htm

本文链接

那个我们爱的Silverlight

2010-10-31T15:43:00Z

写这东西多少有点跟风的意思，不过最近的事还有大家的话多少让我回忆起一点对SL的旧感情。

离开微软的时候我巴巴地主动把手里写的SL控件（Menu/MenuItem）邮件给SL组的人，其实那时候都已经决定要走了，然后还给他们留了私人邮箱，说以后有问题还可以找我，虽然到现在也没看他们用上。所以说说实话我从内心深处是希望SL好的。

做为一个纯粹的技术人员，我看到的SL1.0是一个简单但是充满希望的产品，到了SL2我看到的就是一个曲意攀附.net的商业化妥协产物。

好吧，技术人员还是谈技术吧。不知道大家记不记得SL1.0里面的这个用法：

item["ItemControl.source"]=//...

意思是ItemControl为其中的item附加了一个属性，当然因为JS的特性，ItemControl.source必须写成字符串的形式。提起这个是为了说，其实SL当年的志向并非一个UI framework或者浏览器插件那么简单，它是想做一个类似CLI的运行时。

Silverlight运行时最初设计的基础就是Dependency Object和Dependency Property（简称DO和DP），估计接触过Silverlight的弟兄们多少对这两个东西的存在应该是存疑的，估计也很少有人愿意去理解它们背后存在的道理。

其实相比JS用属性字符串名去访问属性，DO/DP是一个更加高效的动态语言运行时实现，你可以根据属性名去查找属性值，也直接根据DP对象去查找一个属性值，这比属性名快速的多。这个体系允许你在任何对象上添加任何属性，这是比较接近动态语言特性的。——是的，这两个概念根本就不应该让程序员去知道和理解，这是语言运行时的实现方式。

到了光芒万丈的Silverlight2，这个清晰的技术发展路线被扭曲了，微软的老板们只关心一个结果：开发者可以用C#开发Silverlight。当然也这也是无数程序员愿意看到。但是从来不曾有人追究到底如何去实现这件事。

如果SL希望继续走它的"运行时"伟大梦想，它要做的事情就是在DO/DP体系上实现.net CLR，大家都知道在一个更加"动态"的运行时上实现一个更加不动态的运行时是可行的。另一条路，则是在CLR上实现DO/DP，这样做的直接后果是C#仍然跑在.net CLR上,但是必须用奇怪的语法去访问SL对象：

Control.getDependencyProperty(new DependencyProperty("width"))

但是我想是个人都知道前后两种方法哪个工作量更大。

而且那些奇怪的语法并非无法修补——只要你愿意为每个属性写一个getter/setter

看过SL源码的人一定都知道SL团队最终做了怎样的选择，对于只有几十个控件SL而言，写几个getter/setter不过是一个程序员几天的工作量而已。我不曾参加SL团队，所以我不知道什么内幕消息，但是结果大家有目共睹——SL团队最终选择了饮鸩止渴的做法。

于是SL团队当然地以极高的速度完成了引入C#支持的任务，这对SL团队而言，我想也是极其重要的Achievement。坏处？坏处就是，当初那个做"运行时"的构想终结于此，还有就是以后每一个控件的每一个属性，都必须有一个DependencyProperty和一组getter/setter，这还没完，微软还必须维护SL中的这个精简版CLR——事实上，此后很长一段时间里MVP和微软的人都在解释这个被阉割过的CLR跟.net CLR之间的关系。

SL在UI编程模式的设计和抽象方面做的过于优秀，即使如今的HTML5，我也觉得远远不及，UI模型不是靠一两个Sample就能说清楚的，HTML5再好，也不过是多了几个标签——说实话早该加了，只是W3C不够给力而已。

看到IE9声明支持HTML5大家一副心慌的样子我笑了，IE什么时候支持过Silverlight了？如果不是同样打着MS的标志，恐怕大家根本就看不出SL这东西其实跟IE是一个公司的吧？就算微软的IE不去支持HTML5,估计结果也是IE9团队解散或者一帮人没事混日子，绝不可能出现IE支持Silverlight这一出戏。

所以说，搞死Silverlight的绝对不可能是HTML5,只能是Silverlight自己。

本文链接

我理想中的HTML和CSS

2010-09-06T06:30:00Z

任何属性和内容都能以url的方式导入比如 <p innerText="http://xxxxxx.com/content.txt%22%3E%3C/p>

一个页面所有请求的资源可以被预先加载，可预测的资源在一个http请求中就获取到浏览器端

style不再做为属性或者标签，而是做为一个页面描述渲染的文件导入——对不同设备，可以由服务端决定返回什么样的Style Sheet,即使给盲人用的语音浏览器，也能返回一个描述断句和重读之类的文件，而不是一成不变的CSS，这就实现了真正的表现和语义分离

Style Sheet可以嵌入脚本，有点类似expression但不是那么恶心的实现方式，Style Sheet也可以控制所有交互，比如Onclick，hover,mouseIn, mouseOut

不同的css计量单位可以互相运算比如 width:300px-1cm+10%

Style Sheet可以控制标签的一切行为：甚至能用SVG来完全控制标签的形状

视频、音频只是Style Sheet级别的事情，<h1>乱世佳人</h1>也能通过Style Sheet被解释成这部电影的视频播放窗口

<ball />可以通过Style Sheet被显示成一个3D球体

Script不再以标签的方式嵌入HTML 而是独立的一个描述交互的文件提供脚本中同步载入脚本的功能

本文链接

(搬家文) c++引用深入探讨

2010-07-14T16:08:00Z

(偶然翻起自己的旧博,忽然发现大三的时候写的这篇文章,仔细看看觉得写的还是那么回事,所以赶紧搭救出来)

引用的声明: 基本格式：引用类型 &引用名=被引用对象

&运算符：声明运算符& 跟取地址运算符&和位异或运算符&没有任何关系
extern关键字:一般情况下引用的声明必须指定被引用对象唯一的例外是使用extern关键字
const关键字:一般情况下被引用对象必须是有效的左值对象但是const关键字修饰的常引用类型允许被引用对象不是左值对象

引用的使用:引用可以被当作被引用对象的别名使用，单纯的引用是无意义的，引用主要应用于四个方面：

函数参数：可修改的实参，高效的复杂对象传递方式
函数返回值：不产生复制的返回值，返回左值类型的函数
运算符重载：为++ -- << >>等运算符提供了更贴近原意的重载方式
多态：代替指针使用，实现抽象类的引用

引用的深入探讨：现在开始进入正题

1.引用占内存空间吗？

如果引用只是一个别名的话他不应该占有内存空间　我用下面这段代码来查看

#include <iostream>
using namespace std;
void fa(){
    int a[4];
    cout<<a<<endl;
}
void fb(){
    int a[4];
    int &b=a[0];
    cout<<a<<endl;
    fa();
}
void fc(){
    int a[4];
    cout<<a<<endl;
    fb();
}
int main()
{
    fc();
    getchar();
    return 0;
}

这段代码里　我用了三个嵌套的函数调用　这样　ｆａ　和ｆｃ的栈段就把ｆｂ夹在了中间　ｆｂ的栈段大小变化的话　会导致ｆｃ中ａ的地址偏移　但是并不是每个分配都会导致栈段增大的　所以应该先测试一下　确定ａ的合适大小　使得一旦声明变量 b的栈段就增大。

把int &b=a[0];注释掉的话可以看到fc中输出的地址变了 fb没有变那么引用b显然占据了内存空间我的代码在g++中编译，结果也是g++的结果。

2.引用的值不可改变吗？

一个已经初始化的引用类型对象其引用的对象不可能被合法的改变。

前面一段代码展示给我们引用确实占据了内存空间，了进一步了解其本质，我们必须获得它的地址。&取地址操作符显然是无法做到的几乎每个学c++的人都会尝试用这种办法去取引用类型的地址，但得到的都是被引用对象的地址。

还从前面的例子入手 fb中 a的地址没有改变 fa中a的地址改变那么 int &b的分配应该在二者之间于是最可能的位置就是a中的a[4]   但输出之后我发现a[4]不是，因为数组a是跟栈逆向分配的之后我试了这样的代码
void fb(){
    int a[4];
    int b=20;
    cout<<a[-1]<<endl;
    fa();
}

在我的编译器中 b跟a[-1]总是相等于是我把int b 替换成int &b=a[0]; ok 我发现它指向了一个貌似地址的东西。改变b的指向发现a[-1]是随之变化的现在我几乎可以确定 a[-1]就是b了再用一段这样的代码来检验
void fb(){
    int a[4]={1,2,3,4};
    int &b=a[0];
    a[-1]+=4;
    cout<<b<<","<<a[0]<<endl;
    fa();
}

引用真的是不可改变的吗？在这个例子中我使b指向了a[1] 而不再是a[0]

3.引用和指针
从上面的例子看出引用的内部实现和指针并无两样。如果参考其他语言的思想的话可以得到结论：引用就是指针常量。在c++中引用在语法上与指针有着明显的差异但是他们并没有本质不同引用是c++中实现的一种限制比较严格的常量指针它在参与任何运算之前自动解引用。

在使用中推荐尽量用引用代替指针，因为引用是一种比指针更安全的类型并且有更清晰的语义（当然指针也有适合的语义）

4.其他语言
顺便一提，在C家的其他语言中引用几乎被作为访问对象的唯一手段

C++:有指针所有运算符会解引用所有对象不作为引用传递参数和返回值时如果不希望复制则必须将形参指定为引用类型
C#: unsafe模式有指针除了=之外的操作符会解引用所有对象作为引用传递参数和返回值时如果希望复制则必须显式clone
Java:无指针除了=之外的操作符会解引用类似c#
javascript:无指针但是可以变通除了=之外的操作符会解引用没有提供复制传递的方法(郁闷)

本文链接

Visual Studio，不只是用来拖拖控件

2010-07-06T17:33:00Z

一会用IDE，一会不用IDE，我可真烦人......

And,继续标题党下去吧...... 我对拖控件这种标题党方式很有爱。

言归正传，搞过一回命令行编译C#，这回咱们回来玩玩IDE，这一篇主要向大家讲一下VS项目的可定制能力，它并非是微软创造出来的一个专门给.net和Win32编程新手用的玩物，而是一个真正非常优秀的可扩展的IDE产品。你可以用它来管理项目和项目依赖关系，可以跟源码管理工具集成，编译执行也不限于微软内置的集中开发语言，你甚至可以用它来开发Java。

这篇文章将会通过一个简单例子，来演示如何用VS来编译ilasm，这个应该也还是有些实际用处的，也方便喜欢研究ilasm的朋友。

首先第一步，我们建立一个C++空项目（没错，是C++空项目，对VS而言，VC++是一种自定义项目，它最接近我们的需求）。

接下来我们右键点这个新建的项目，选择“工具生成顺序”，然后把那一堆C++工具全都选掉，只留下自定义生成工具就行了。

好这样我们的项目就编译不了C++了。

接下来是重点，重新在VS中打开项目文件，然后右键点击“自定义生成规则”

然后我们新建一个规则文件，用来编译il文件。

新建一个规则文件之后新建规则，到这都很容易，就不用细说了。

新建规则稍微有些复杂了，首先我们来参考一下ILASM的文档：http://msdn.microsoft.com/zh-cn/library/496e4ekx(VS.80).aspx

我这里只是为了演示，没有把太多的ilasm编译选项做成属性

填好后一路确定就行了。可以在项目中改变自定义属性来切换exe和dll：

附上MSIL的helloworld以供大家验证：

// HelloWorld.il
// This is our first IL program!

.assembly extern mscorlib {
}

.assembly HelloWorld {
  .ver 1:0:1:0
}

.module HelloWorld.exe

.method privatescope static void Main() cil managed {
  .maxstack 1
  .entrypoint

  ldstr  "Hello World"
  call  void [mscorlib]System.Console::WriteLine(string)
  ret
}

附上整个项目压缩包：

/Files/winter-cn/ilasm.rar

本文链接