|
|
首先感谢拓荒者为我们提供了错误样本。其次感谢kaneboy把这个错误报告上去，并告诉我们这却是一个Bug，并且知道这个Bug在桌面上的所有x86版本的.NET上面都存在。这个Bug预计在下一个版本的.NET 2.0 beta里面得到修正，已有版本的SP就不知道什么时候才有了……这个Bug到底有多严重，见仁见智吧，不想在这里做评论。这里写一下只是让闲得无聊的人见识一下这个奇异现象，或者让真的觉得威胁到自己软件安全的人注意一下。
其次希望微软能给我奖金，或者至少稿费。
该错误在一般使用的情况下很少遇到，但在非常特殊的使用方式下才会产生，尤其在您特意使用一些C#的副作用的时候更容易产生。不过如果遇到了，说不定真是会损失惨重。（我个人感觉这种错误跟Intel多年前奔腾芯片的浮点错误非常神似。）
错误简述：
如果您的程序：
1、在某个整形变量上面进行不带检查的加法操作(unchecked，默认的行为方式，不包括减法、乘法、除法操作)，并且产生溢出（溢出后数值必然是负值），并且
2、立刻紧跟在该加法操作后面判断是否小于常量零(加完之后有乘除或者函数调用等，或者判断的是某个变量里面的零，或者判断的是小于其他常量值等，都不符合该条件)，并且
3、在该函数当中使用了该变量的引用，例如：a.XXXX() 或者 AnotherFunction(ref a)。
或者与此相反的：
1、……减法……（……正值）……
2、……大于常量零……
3、……
则会引起上述第二步的判断与我们的期望不符——似乎该数大于等于0，并且因此没有执行该条件分支的语句或者语句块。
下面是错误重现：
1、在C#里新建一个Console项目
2、插入下列代码：
class Test
{
static void Main()
{
int a = 0x79de61c0; //2044617152;
a += 0x12345678;
//a 应为 0x8c12b838; //-1944930248
if( a < 0 ) a = -a;
System.Console.WriteLine( a );
string str2 = a.ToString();
Console.ReadLine();
}
}
3、运行后发现，if(a<0) a = -a; 这一句话出现瑕疵，a < 0 测试出错，并因此没有执行后续的 a = -a 语句。
当我们去掉 string str2 = a.ToString(); 这一句话之后，错误消失。
下面是对该问题的具体分析：
该问题实质上是由于JIT引擎翻译逻辑有瑕疵引起的。当注释掉string str2 = a.ToString() 之后，我们调试时打开反编译窗口以及寄存器窗口。在寄存器窗口上面点击右键，选上“标志”。此时我们可以看到：
请注意图片黄色箭头处，if(a < 0) 实际上被翻译成jns 0016。jns机器指令的含义是，如果不是负数则跳转，实际上判断的是“符号标志”，也就是途中红圈圈上的"PL"，这个标志位（以及其他一些标志位）由上一个指令add产生（这是该指令的副作用）。 由于符号为负，并没有条件转移，因此能够执行下一句a = -a （也就是neg esi）。但是请注意图中另外一个寄存器标志OV，该标志表示“溢出”。很明显我们的代码是因为相加溢出才导致结果变为负数，所以该标志位被置位。
当我们再去掉string str2 = a.ToString(); 并运行之后，我们可以看到：
注意图中红圈处，原来的jns指令现在被改为jge指令。jge机器指令的含义是，如果大于等于则跳转，实际上判断的是“OV”、“PL”，相当于if ((OV ^ PL) == false) goto xxx。也就是说，多关注了一个OV标志。
很明显由于前面的溢出，造成OV标志置位，因此条件转移成立，结果没有执行后续的neg esi。所以我们从源代码的角度看，似乎此时变量a的值是非负数，这跟该数为负数的事实不符。
尽管从源代码的角度看，似乎没有任何与if(a < 0)有关系的改动，实际上由于我不清楚的理由，当该函数中使用到了a的引用，结果造成了if(a < 0)翻译成机器指令的不同，进而对一些副作用的反应不相同。
此例当中对a的引用是a.ToString()，实际上如果您使用AnotherFunction(ref a)替代这一句话，也会引起相同的问题。与此相反的减法操作的问题，原因和解释类似。
该问题的解决方法：
1、尽可能不要利用C#相加/减溢出后变成负数的副作用，例如用下列方式避免副作用：
checked
{
a += 1234;
}
2、如果您确信相加后溢出的副作用是必须的，那么请采取下列措施避免该错误：
a += 1234;
b = a;
if (b < 0)
{
a = -a;
}
注意，这个并非微软的官方解决方法，目前我并不清楚微软的KB里面是否有该问题的纪录。
p.s.: 有人告诉我，不一定非要有对a的引用才会引起问题，具体我也不研究了，反正对a进行引用一定出问题。（也许是对其他的引用产生了ldloca之类的il代码吧，没有研究过）
好久没有上来写点什么东西了，也有一段时间没有到博客堂拨客园上面来采风了，今天一上来就看到这个文章： 数据类型的BUG还是??? 里面罗列了一些问题，也许我能略解一二。比如说问题二：
dim ss as double
ss = 400*1000
在VB6中,报越界!!
ss = 400*100000没有异常
其实是这样的，VB6里面对于常数，如果没有带数据类型标志符（例如#）或者小数点，就认为是整数。而对于实际上是什么整数，则根据最小化原则，认为400和1000同为16位带符号整形。而数值计算结果的数据类型和操作数中表示范围最大的相一致（其实大部分语言都是这么定义的。ps:对于VB6及以下版本，似乎没有应用常量传播，要到计算里面才会出错），很明显400*1000的计算结果超出16位带符号整形的表示范围，报越界。而400*100000里面后者被认为是32位带符号数值，因此计算结果也是32位带符号数值，所以不会越界。
请注意，大部分语言的计算过程是有一个中间计算结果的，这个结果跟最终承载变量没有关系，而跟该语言的运算法则相关。在本例当中无论ss被定义为double、long还是别的数值类型，都必然会引发越界，这是由VB6里面的语言定义所引起的。而中间计算结果要经过一个转换过程才能够得到最终变量的数据类型，一般的基本数据类型之间都有“隐式”转换，有的是强制转换，这个一般由语言本身所定义。例如在VB6里面，几乎所有数值类型之间都能够自由的进行隐式转换，但是在C#里面，浮点数转换为整形数字的时候就必须要强制转换。
当然，从某种角度来讲，所有数值类型之间能够自由的隐式是VB6语言定义本身的缺陷，因为这样可能会引发很多“看不见”的问题。但是这实际上是VB6语言本身的定义，而不是设计人员无意识的或者不期望的结果，所以我宁愿称之为Fault也不愿意说是Bug。
可是大坏蛋却说.NET里面：
double ss;
int firstInt = 2147483646;
int secondInt = 2;
ss = firstInt + secondInt;
Console.WriteLine(ss);
结果:ss = -2147483648
似乎对这个现象有点意见。首先，还是那个原因，计算是有中间结果的，中间结果的类型在这里仍然是int。其次，要追溯C语言本身的处理方式，在C语言里面不会对整形的上下界超界产生任何疑问，甚至不会报错。因为这个被认为是C语言的“特性”之一，C#“号称”继承了C/C++，那自然也会尽可能继承这些传统习惯，因此他就作为语法规范里面的一部分了，无可厚非。而事实上这也不是.NET Framework的功劳，而仅仅是C#的定义而已。因为在VB.NET里面，这会产生异常的。因为在C#的编译器对整数加减法使用的是不带检验的IL指令，而VB.NET则使用的是待检验的IL指令。比如C#使用的是add指令，而VB.NET则使用的是add.ovf指令。当然，这是在最普遍的代码编写方式，以及默认的语言参数下面而言的。
如果有什么疑问，请尝试下述代码：
int ss;
int firstInt = 2147483646;
int secondInt = 2;
ss = firstInt + secondInt;
Console.WriteLine(ss);
呵呵，现在再请没有疑问的尝试下述代码：
int ss = int.MaxValue + 2;
回过头来我们再看看第一个问题：
dim ss as double
ss = 194268.02 – 194268
肉眼可以判断结果为0.02,而VB中计算的结果:ss = 0.199999999895226E-02
ss = 1.2 - 1 VB计算的结果为:0.2
要知道这个问题的答案，我们首先要看看这里的浮点数到底是什么浮点数。在.NET Framework里面（以及VB/VC等）遵循的是IEEE标准，那么为什么0.02不是0.02了呢？其实这个在IEEE里面可以找到一个快速的解答。那么为什么后面一个计算会是正确的呢？那其实是因为“精度”足够，使得你认为它就是0.2。事实上IEEE浮点数永远不可能精确等于2的n次幂相加所构成的数值（比如1.375 = 20 + 2-2 + 2-3，我“简称”这种数字为“可被2整除的数字”。），除非IEEE更改了他的标准。（关于IEEE浮点数的定义可以参考这里。）顺带给出double的1.2和0.2的十六进制编码：
1.2 = IEEE_double(3FF3 3333 3333 3333)
0.2 = IEEE_double(3FC9 9999 9999 999A)
而1.2-1的运算结果却是 IEEE_double(3FC9 9999 9999 9998)，看到了吗？其实1.2 - 1并不等于0.2的。而事实上IEEE浮点运算即使是在“可被2整除”的数字之间进行，通常都会有误差的，这主要源于精度丢失。前面的1.2 - 1的误差并不属于这个范畴，这主要是由于操作数本身无法被精确表示而造成的（虽然也有精度丢失的原因）。可以说精度不丢失的情况是相当特殊的，比如说完全相等的两个数相加减，乘、除以2的整倍或者正负1以及0，和0或者“非数字”之间的计算，等等。
所以说这些问题千万不要往MS的头上扣，也不是MS所能够改变得了的。
今天看到朋友 wayfarer写的 一篇文章，大概是关于protected的“保护性”问题的，看过之后内心有些想法想与大家分享，如果大家不嫌弃，敬请往下看。 拍脑壳所想之
——戏言面向对象
说到protected这个词，我不可避免的就会想到一个概念——面向对象。那么什么是面向对象呢？其实我个人认为面向对象这个概念是一直在发展变化的，到了今天，面向对象这个词也许让它叫做面向抽象更加贴切。在刚刚建立面向对象这个概念的时候，大概连创造者对于到底什么是面向对象都不是很清楚。要搞清楚面向对象（编程，或者设计）是什么，也许得看看过去的软件代码都是什么样的。
 I.公元前
软件开发在最初的十几二十年里面，基本上就是面向过程的。面向过程的核心内容有两项，一个是控制流，另外一个就是数据流。在这一个时期里面，软件界最大的发展估计是数据结构与算法这两个“科目”了，这两者分别对应着两个“流”。在面向过程的软件代码里面，执行主体是过程或者函数。一个过程所代表的就是一个动作，动作的对象（这里还不是面向对象的对象）是一些数据，数据也许通过参数得到，也许通过全局变量得到，还有一些常量或者预定义值。如果我们仔细想一下，就会发现这是一个“动宾”结构的体系，比如说Basic里面比较著名的“Line (x1, y1) -(x2, y2)”，翻译成自然语言就是“画一条(x1,y1)到(x2,y2)的直线”。类似的例子还有很多，比如C语言里面的“printf("%s\r\n", "Hello world!");”。 可是主语在哪里？
 II.创世纪
面向过程的代码里面并没有突出一个主语，很多时候这个主语也并非不存在，就像上面的例子里面，主语就是一个屏幕。可是如果我们需要往打印机里面画一条直线呢？（或者打印一个"Hello world"。）在面向过程的代码里面，我们就不得不自己写一个PrintLine的函数。（C语言往文件里面些东西就是fprintf。）如果我们要往远程设备上画一条直线，那还要写一个RemoteLine，如果……不需要我多说，您也会觉得麻烦。围绕着这样一个问题，人们就开始思考：是否能够把主语明确的给写出来？是否能够让我们少做一点重复性的工作？后来就有了面向对象这个东西，在面向对象是一个“主谓宾”结构的世界，绝大多数东西都有一个主语，比如我们所熟悉的“g.DrawLine(pen, pt1, pt2);”，由于我们有了“主语”，我们就可以让不同的东西，用相似的方法做相似的事情。如果光是把g换成h，仅仅解决了“在这个窗口画”与“在那个窗口画”的问题，如果我们希望他能够在其他类型的空间上画，我们还需要容许主语的类型可以不完全相同。但我们要解决的更多问题还是概念相同之处，例如打印机的g和屏幕的g都能够画线，因此有了诸如继承、封装等概念。这就是面向对象的一切了吗？
 III.改革开放
随着面向对象概念的诞生，春风沐浴大地。正如上帝说要有光，于是有了光。上帝说要有毒蛇，于是有了毒蛇，上帝说要有苹果，于是有了苹果，结果亚当和夏娃吃了这个上帝创造出来的苹果受到了上帝的“惩罚”。真不明白，既然上帝不希望亚当和夏娃吃这个苹果，为什么还要创造这么一个东西？其实上帝创造这个苹果当然是不希望他们“吃”这个苹果，创造这个苹果实际上是为了产生浪漫的爱情以及其后千秋万代的动人故事。如果你把这个苹果仅仅看成是吃的，那么接下来你看到的就是痛苦的惩罚。如果你看到的是背后动人的故事，那么浪漫甜蜜等美好之辞就会充满你的大脑。 面向对象也一样，他的核心意义并不在于你把东西封装成什么样了，不在于有什么东西被继承出来了，最重要的是他容许我们用抽象的方式来构建一个软件。比如当我们写代码写到： stream.Write(buff, 4, buff.Length - 4); 或者 hashbuff = hasher.ComputeHash(buff); 我们是否需要关心stream到底是什么，hasher用的又是什么算法呢？如果我们由始至终，在做相应的东西的操作都用相同的stream对象和hasher对象，任务是否都应当能够正确完成呢？应该是能够正确完成的，因为这正是我们的期待。如果让我们来设计某一个stream，是否应该从这个角度去考虑如何设计这一个类呢？如果我们定义这个stream变量，是否应该更抽象一点呢？考虑这么一个函数： void DoSomething(FileStream stream, MD5CryptoServiceProvider hasher, byte[] buff) {...} 如果写成如下形式将会更加灵活，也更加符合面向对象（面向抽象）的真实含义： void DoSomething(Stream stream, HashAlgorithm hasher, byte[] buff) {...} 换句话说，所有的封装、继承、接口等等，实际上是为了提供抽象能力而存在的。如果我们把protected当作保护“某些方法的存在”这个秘密的话，那就大错特错了。保护这些秘密严格说来应该是密码学的职责，而不是面向对象的职责。
 IV.回顾历史
面向对象的核心是面向抽象，但我们看到，实际发展的过程并非如此。我们在过去有着太多错误的概念了，比如说这个面向对象技术的面向对象，就太容易让我们认为，这项技术的核心就是面向对象。于是很多时候我们写一个“面向对象”的程序充斥的过度的对象，泛滥的继承，以及不知道为什么的封装。并且不少开发者，包括我在内，都曾经认为所谓的面向对象就是把一些要素抽象成对象，进行封装，然后从某个基类派生出万物。好比有一个基类叫做物体，派生出活物与死物，活物派生出细菌病毒植物动物，动物里面有猴鸡狗猪和人，人里面有张三李四王二麻子（还有个娃）。 没错，面向对象当然得包括这些，但是这不是全部，更不是根本。根本就是在于我们写某些东西的时候，不需要关心具体的对象是什么，只需要知道至少它应该是一个什么。比如上一节当中的例子，DoSomething只需要知道stream是一个流，而hasher是一个哈希算法提供者就够了。至于具体提供的是什么样的流和哈希算法，则不应当是我们关心的，而是使用我们这段代码的用户所关心的。如此一来，我们就可以在设计这一段我们所关心的功能的时候，不需要考虑过多的、过于具体的、不断变化的问题。 仔细想想，我们是否真的已经明白了面向对象的核心所在呢？
 V.封装保护的是什么
面向对象的封装并非保护你的秘密，而是防止被错误使用，是为了明确划分问题的界限。就“保护”这个词而言，更进一步的讲，它并非对使用该对象的用户（下面称为用户）做出使用某个成员的授权，而是对延展该类的设计人员（下面称为设计人员）做出延展问题领域的授权。现在让我们回过头来看一下 wayfarer所写的例子：
 class Base
   {
 protected void Print()
  {
Console.Write("This is protected method in Base Class!");
 }
 }
class Derived:Base
{
public new void Print()
{
base.Print();
}
}
class OtherClass
{
[STAThread]
static void Main(string[] args)
{
Derived d = new Derived();
d.Print();
Console.ReadLine();
}
}
这个例子确实是非常容易迷惑人的，曾经，我也被这样的问题所困扰。在解决这个困扰之前我们首先要弄清楚下面两个问题：
protected是什么？new又是什么？
protected 很好回答，他表明该成员容许在派生类当中被使用，但不允许使用本类对象的用户代码直接使用。实际上是对设计人员的有限度授权，和对用户的拒绝授权。
而new也并非难以回答，比如说：他是为了在没有override的情况下造成一种被重写了的假象。如果您真的这么认为，那就掉入了幻觉的漩涡当中去了。事实上new的作用并非一个trick，让你可以造成各种各样的假象，或者企图绕过某些使用与设计的授权。new的作用仅仅是为了解决一个命名冲突的问题，也就是说new所指定的成员实际上与基类的同名成员毫无干系，只是非常抱歉的跟他重名了只好声明此Print非彼Print。如果您真的企图用new来制造trick假象的话，终究是要撞掉你的门牙的。在我举出“撞掉你的门牙”的例子之前，请容许我首先给出一个正确使用new关键字的场景。
不知道各位有没有真正的研究过.NET Framework里面interface呢？如果研究过，对于下面的这个问题应当不是非常难以回答。
public interface IFoo
{
bool Bubble();
}
public class Boo
{
public void Bubble()
{
}
}
public class Foo : Boo, IFoo
{
public bool Bubble()
{
}
}
上面这个代码会在Foo的Bubble函数上面产生一个警告，但是仍然能够编译通过。为什么能够编译通过呢？这个问题留给读者自己琢磨了。解决这个警告的办法有两个：一个是显式实现接口IFoo；可是如果我不希望通过显式的方式来实现该接口，那么就只能够在Foo的Bubble函数前面添加一个new修饰符，告诉编译器我知道他们有冲突，但是我还是希望选择用这种方式来完成它们。这两个Bubble相同的名称给我们一种它们之间有什么联系的错觉，事实上 new bool Bubble() 与 bool new_Bubble() 的含义接近，和Boo里面的void Bubble可以看作毫无关系。如果你觉得有关系的话，那么下面的我将举出一个例子让你碰一鼻子灰。
public class Boo
{
public void Bubble()
{
Console.WriteLine("Boo sheet");
}
}
public class Foo : Boo
{
public new void Bubble()
{
Console.WriteLine("Foo sheet");
}
}
class Program
{
static void Main(string[] args)
{
Foo obj = new Foo();
Test(obj);
Console.ReadLine();
}
static void Test(Boo obj)
{
obj.Bubble();
}
}
你猜你会说Boo sheet呢，还是Foo sheet？为什么会这样也请自个儿思考一下。
wayfarer所举的那个例子，看起来确实容易造成困惑，或者会让大家觉得这里有一个暴露protected函数的bug，但事实上并非如此。还记不记得前面我说过了，protected是一个授权问题，而非保密问题，这一个说法应该能部分解决您的困惑。而上面的Boo sheet例子表明，实际上你并没有暴露那个protected函数，因为你仍然无法直接从一个指向Derived实例的Base变量上面寻求到使用Print函数的方法。如果您还记得我前面说过的面向抽象这个概念，也应该意识到，您写的Derived类只是对Base类的补充，而用户一般应该用Base变量来使用您的对象，而不是Derived变量，除非他认为他需要使用Derived提供而Base不提供的功能。如果说我不使用new关键字，而是把Derived的Print函数命名为PrintBase，那是否算是会引起“暴露”基类成员的Bug呢？
显然不是。此时如果用Base变量仍然无法访问Print，用Derived变量则仍然可以访问到PrintBase（并最终调用Print）。还记得派生是为了延展问题领域的边界吗？这里将Base的一个受保护函数暴露出来，就是延展了问题领域的边界。设计Base的人认为，Print的功能是对象的内部事务，而Derived的设计人员则认为Print功能应该是外部与内部之间的事务，此时是否仍叫Print已不重要了。（P.S.: 容许派生类使用，却不允许被暴露，这是根本不可能的事情，即使new关键字不存在也一样。而真正能够称之为“暴露”的是反射邦定/反射调用等。可惜我们还是不能够称之为Bug，因为这正是“反射”这个设计所期望的功能，而非不小心造成的有害副作用。）
说到这里，我想protected和new的问题应该已经讲完了。还有什么疑惑吗？
 VI.回到未来回过头来再说说面向抽象，以及面向接口。 前面已经提到了面向抽象了，不知道大家是否有更多的感想。抽象到了头是什么？当然不是什么都没有，不是虚空太极。抽象的本质是描述某个主语能够完成一组什么动作，这些动作构成了什么样的功能。如果我们从这样的一个角度去想，就会发现接口能够很好的完成这样的任务。比如说IList，它表达的是“一个列表”这样的抽象，这个抽象能够提供一组相应的动作，比如"object this[int index];" 能够取出或设置列表当中的第n项内容。只有拥有IList接口所定义的成员，才能够表明这个物体确实能够称之为“一个列表”。“服务”这个词也许能够更加深刻的表达上述的含义： class ArrayList : IList {...} 这样的定义表明，ArrayList提供“列表”相关的服务。如果我们在定义变量和参数的时候更多的使用接口，而不是具体的类，那么我们的代码将拥有更大的自由度。这个时候我们关心的事某个对象是否能够提供我所需要的服务，而不关心他到底是什么。 在面向对象刚刚开始的时候，我们在这个方面走进了一个误区，就是用多继承来解决上面的这个需求。比如我们可以在C++里面看到Stream派生自IStream和OStream，这么做也能够解决问题，也许同样能够表达“服务”这个含义。但是我觉得这样做还是会引起许多不必要的麻烦，比如同名称冲突等。现代的理论甚至直接告诉我们继承他不是一个好东西，如果能够用引用来代替继承，那就不要继承，如DesignPattern里面的Decorate等。
真正未来的理论是什么，我不知道。但是至少我看到面向接口的设计思想比“面向对象”要更为先进，而目前真正能够这样思考的人远比知道如何封装继承的人要少得多。从这个角度讲，那也算是未来的技术，至少是未来需要普及的技术。（现在COM不就是这样一种思想吗？）
一个强制转换快还是ToString快，搞得我晕头转向的。以为OK了出结果了，却出现奇怪的情况，还好，总算是山穷水尽（复，李敖说的）疑无路，柳暗花明又一村。
一开始，我想大家都跟我猜想的一样，认为ToString比较慢，而且还有危险。结果一开始我的试验结果跟我的猜测比较吻合，ToString比强制转换要慢一个级别，不同的机子上面会有不同的结果，在10：1到6：1之间。但是后来有人说在Console下面不一样，问题就变得让我困惑起来了。事实上这个跟GDI，跟Form本身，跟DoEvents函数统统没有关系，因为我没有动用到无关的东西，也没有把非必要的部分给测量出来。更让我感到有趣的是，即使是在Console下面，只要自己写的类继承自Form，测试结果就会变慢。如果取消继承关系，两者的速度就会相差无几。认为Form的初始化会比较复杂，会动用Native资源，会在释放对象的时候有效率问题，这些都是错的，因为我很明显没有不断的进行构造和释放，也没有把这部分的时间计算在内。那么到底是什么问题呢？昨天没有时间进行试验，今天一大早起来就是为了进行测试。
其实我一开始就在汇编底下注意到那个ToString之后的调用，总觉得很奇怪：为什么不用强制转换之后的那一个赋值调用呢？（就是下面这个）
00000112 mov esi,eax
00000114 push esi
00000115 mov ecx,edi
00000117 mov edx,995358h
0000011c call 71E7021D
所以我从一开始就怀疑性能损失在这个地方，但是因为暂时没有办法调式到内部（MS的调试器……），所以我只能够进行一些猜想：是不是跟测试所在的实例有关系呢？
用一句代码来举一个例：
s = o.ToString();
本来觉得性能应该仅仅取决于调用了什么方法（ToString还是强制转换），以及所调用对象本身的类型（跟o有关）。比如考虑到ToString是虚函数，也许会有关系。但是后来看到这一系列奇怪的结果之后，不得不怀疑这个测试还跟this有关系。
首先我就猜测，是不是跟继承的深度有关系？如果是这个问题就太荒谬了，但是Form类和自己写的类之间的差别之一就是继承深度，还是有嫌疑的理由。为了验证这个问题，写了两个类：
public class TestBase
{
protected const int testRound = 100000000;
private string sTestBase;
public void Test();
}
public class First : TestBase
{
private string sFirst;
public void FirstTest();
}
构造相应的实例并本别调用Test和FirstTest，函数内部的代码大致如下：
object o = "Hello! this is a test!";
long dt;
int i;
dt = DateTime.Now.Ticks;
for (i = 0; i < testRound; i++)
{
sFirst = (string) o;
}
dt = DateTime.Now.Ticks - dt;
Console.WriteLine(dt.ToString("N"));
dt = DateTime.Now.Ticks;
for (i = 0; i < testRound; i++)
{
sFirst = o.ToString();
}
dt = DateTime.Now.Ticks - dt;
Console.WriteLine(dt.ToString("N"));
这里写成两个函数主要是避免虚函数可能带来的影响，尽管不太可能，还是不要节外生枝比较好。测试的结果表明几乎没有任何差别，我还是不死心，把继承深度从1层扩大到3层，测试结果还是一样，因此排除了继承深度带来的影响。
然后我只好怀疑是否因为对象内部实现了某些接口造成性能上面的差异，因为Form内部确是有实现不少的接口，尽管也挺荒谬的。于是我又写了一个类：
public class Second : First, ICloneable, IComparable, IFormattable, IServiceProvider, IDisposable, IConvertible, ICustomFormatter, IAsyncResult, IAppDomainSetup, IDbCommand, IFeatureSupport, IFileReaderService, IContainerControl, IDataAdapter, IButtonControl, ICommandExecutor, IDbDataParameter, IColumnMapping, IMessageFilter, ITableMapping, IWin32Window, IWindowTarget, ITableMappingCollection
{
private string sSecond;
public void SecondTest();
// 接口实现就不贴上来了
}
不要怪我狠心，我开始的时候添加了三个接口，观测到几十毫秒的差异，于是就一路添加上去。最后发现差别不会超过100毫秒，并且很可能是误差造成的。现在添加了二十多个接口都没有问题，那么到底问题在哪里呢？
再看就剩下Form的父类没有研究了，难道还真的是构造函数里面有些损耗性能的东西？那就太郁闷了，也非常荒谬。没办法，猜测不解决问题，还是来测试一下吧。看看怎么个测试法呢？想了想觉得还是从最上面的父类开始找问题，也就是说设计一个从MarshalByRefObject派生的类：
public class Fourth : MarshalByRefObject
{
private string sFourth;
public void FourthTest();
}
不测不知道，一测下一跳，问题就是由MarshalByRefObject引起的，试验结果跟前面的10：1非常吻合。后来为了挖掘更多的数据，我做了更多的相关测试，例如测试函数是实例上的，但是sFourth则是静态的结果会怎么样？如果函数是静态的，但是全局变量是实例上的呢？两者都是静态的呢？所以还写了更多的函数来测试：
public void TestStatic()；
static public void StaticTest(Fourth fourth)；
static public void StaticTestStatic(Fourth fourth)；
这个测试我在.NET 1.1(DEBUG)、.NET 2.0(DEBUG/RELEASE)下面分别测试，测试结果数据如下：
| 说明 |
.NET 1.1 DEBUG |
.NET 2.0 DEBUG |
.NET 2.0 RELEASE |
TestBase : object
string = (string) o
string = o.ToString()
First : TestBase
string = (string) o
string = o.ToString()
Second : First, Interfaces
string = (string) o
string = o.ToString()
Third : First
string = (string) o
string = o.ToString()
Fourth : MarshalByRef
string = (string) o
string = o.ToString()
string = MyClass.GetString()
string = this.GetString()
string = Fourth.GetString()
Fourth
static string sStatic;
public void TestStatic()
{
sStatic = this.someThing
}
Fourth
private string sFourth;
static public void StaticTest(obj)
{
sFourth = obj.someThing
}
Fourth
static string sStatic;
static public void StaticTestStatic()
{
sStatic = Fourth.SomeThing
}
---End of Test--- |
TestBase
10,625,000.00
11,250,000.00
First
10,468,750.00
11,093,750.00
Second
10,781,250.00
10,937,500.00
Third
10,468,750.00
11,093,750.00
Fourth
10,625,000.00
109,062,500.00
110,937,500.00
120,781,250.00
109,062,500.00
Fourth
10,468,750.00
11,093,750.00
11,093,750.00
24,843,750.00
10,156,250.00
Fourth
106,718,750.00
108,125,000.00
109,687,500.00
119,218,750.00
106,875,000.00
Fourth
10,312,500.00
11,093,750.00
11,093,750.00
24,843,750.00
10,156,250.00
DONE |
TestBase
10,781,250.00
15,312,500.00
First
10,312,500.00
15,781,250.00
Second
11,250,000.00
15,468,750.00
Third
10,312,500.00
14,531,250.00
Fourth
9,687,500.00
125,625,000.00
120,312,500.00
131,093,750.00
118,281,250.00
Fourth
8,593,750.00
12,656,250.00
12,968,750.00
27,343,750.00
12,187,500.00
Fourth
117,343,750.00
118,906,250.00
119,687,500.00
131,406,250.00
121,562,500.00
Fourth
8,593,750.00
12,656,250.00
12,968,750.00
28,125,000.00
12,031,250.00
DONE |
TestBase
8,125,000.00
12,968,750.00
First
7,656,250.00
12,968,750.00
Second
8,281,250.00
15,468,750.00
Third
7,187,500.00
13,437,500.00
Fourth
7,812,500.00
12,812,500.00
5,156,250.00
25,625,000.00
6,093,750.00
Fourth
12,812,500.00
15,156,250.00
6,093,750.00
24,687,500.00
6,250,000.00
Fourth
113,750,000.00
115,156,250.00
109,062,500.00
126,718,750.00
109,062,500.00
Fourth
6,875,000.00
12,031,250.00
5,156,250.00
22,968,750.00
5,156,250.00
DONE | （先给大家说一下，大家可以注意一下.NET 2.0 RELEASE的数据，相比较起来是一个比较奇特的数据。） 我一开始万万没有想到，a = b 这样的简单赋值语句还会跟a这个变量声明的位置有关系（都是全局变量的情况下），或者说跟a所在的类有关系。以为不就是把b赋给a嘛，汇编里面一句mov或者lea就搞定了，如何获得b才是影响性能的关键。结果发现.NET下面并不是这么简单的事情，至少会有MarshalByRefObject这个特例。以前也听说过MarshalByRefObject会非常的影响性能，但是文章里面没有提及，自己也没有考究过。心里面想，这个MarshalByRefObject跟我有什么关系？现在想想好象还是有一点点关系的，比如你在Form上面有一个全局变量（包括你放在窗口上面的所有控件都是本地变量），你对他进行赋值就会有性能损耗。然而值得庆幸的是，我们很多时候都不会对一个全局变量不停的进行复制操作，比如我们总不可能对一个Button myButton这个全局变量循环赋值100000000次吧？顶多我们可能对Hashtable ht这个全局变量不停的添加内容，还好Hashtable等集合类型都不是从MarshalByRefObject里面继承出来的，如果是那样的话真是要疯掉了…… 这个发现也许有用，也许没有用，至少在VS2k5里面已经没有什么太大意义了。但是在.NET CF里面就不好说了，虽然我从直观上认为不可能做出太多优化，并且那里面的MarshalByRefObject里面没有任何内容，不知道.NET CF还会不会对其进行特殊对待呢？
首先先说一句不好意思，昨天的Post里面忘了给大家介绍一个基本的前提：那个object o 里面的数据我可以确保它是string类型，也只可能是string类型。这一个研究并不是完全没有意义的，虽然在我实验之前确实也认为应该是强制转换的速度快，但是没有实际的比较问题还是比较难以说明的。也许有人就会问了，你凭什么认为object o里面的就是string呢？不好意思，这是我限定的条件，并且是有实际被应用情形的： 考虑现在我有一个private的ArrayList用于保存用户在TextBox里面输入的字符串，很明显TextBox.Text里面就是返回一个string类型的对象，并且也不可能是null（或者说我通过在初始化的时候给它赋一个string.Empty来避免出现null的情况）。现在我需要将这些保存在那个ArrayList里面的字符串通过BinaryWriter保存到一个自定义格式的二进制文件里面，当然也可能有其他的计算需要我把ArrayList里面的字符串数据进行计算或者处理，这里为了简便随便说了一个也许不是很完整也不是很合理的的例子，但是我相信大家应该明白我的意思了。Hmm，也许还需要另外一个限定，就是没有Generic的支持，比如说这个东西需要在.NET Compact Framework里面实现，而.NET CF即使是到了2.0的版本也不会有Generic的支持。 但是上一次Ninputer说了： 假如o里面原来就是String类型，那么循环100000000的结果是
(string)o 为610ms
o.ToString() 为670ms
这种差距几乎没有意义。
假如o里面是除string之外的其他类型，那么o根本不能直接cast成String。 而同时也有人说，强制转换比ToString要快。那么实际情况是如何呢？请大家先来看看我的代码：
private string testString;
private const int testRound = 100000000;
private void button1_Click(object sender, System.EventArgs e)
{
object o = "Hello! this is a test!";
int i;
long dt;
dt = DateTime.Now.Ticks;
for (i = 0; i < testRound; i++)
{
testString = (string)o;
}
dt = DateTime.Now.Ticks - dt;
textBox1.Text = dt.ToString("#,###,###,###");
Application.DoEvents();
dt = DateTime.Now.Ticks;
for (i = 0; i < testRound; i++)
{
testString = o.ToString();
}
dt = DateTime.Now.Ticks - dt;
textBox2.Text = dt.ToString("#,###,###,###");
Application.DoEvents();
}
这个实验我分别在VS2k3和VS2k5里面实验过，并且分别用Debug和Release两种模式去测试，测试结果如下：
DEBUG: （强制转换：ToString）
@2k3
11,406,250 : 123,125,000
@2k5
10,468,750 : 123,906,250
RELEASE:
@2k3
12,500,000 : 118,593,750
@2k5
7,031,250 : 13,906,250
大家首先会发现如下结论：
1、强制转换的速度在0.7秒到1.3秒之间，而ToString则基本上处于10秒以上的级别（有特例）。所以我极度怀疑Ninputer的测试结果是错误的，因为他的两个结果都是在0.6秒左右，当然还有一个特例跟Ninputer的数据相对接近，但是请继续看下面的结论。
2、这里有一个唯一的特例，就是VS2k5的Release模式，大家可以看到ToString的速度从10秒级别急剧减少为1秒级别，这个就是我题目所说的意外惊喜。但是即使是这样，ToString仍然比强制转换慢了50%，同时该数据还是P4HT 2.8GHz 1G Ram的机器上面测得，如果要ToString达到Ninputer所说的数据，我估计得要P4HT 4GHz以上的CPU，或者P4HT双CPU才有机会。还有，Ninputer的数据仅仅相差10%左右，这个跟我的实测数据完全不吻合。因此我估计Ninputer的测试很可能是因为代码不合理，被JIT短路了（优化了），如果将转换结果保存在全局变量里面，也许就不是这个结果了。
关于为什么VS2k5的ToString在Release模式下面会有这么大的性能提升，我想还需要另外做实验去证明，现在还不好胡乱发言（虽然已经有自己的想法了）。
3、大家如果更加仔细的去看强制转换的数据，就会发现VS2k5无论在哪一种情况下面，都会比VS2k3的数据要快那么一点点，大约10%到30%不等。关于这个我可以马上给大家一个解释，这个实际上是.NET Framework 1.x和2.0之间的问题，但是这需要观察JIT之后的Native Asm，难度有点高。请看片断：
.NET Framework 1.1:
testString = (string)o;
00000063 mov edx,dword ptr [ebp-0Ch]
00000066 mov ecx,79BF9AF8h
0000006b call 71E608BC
00000070 lea edx,[ebx+000000ECh]
00000076 call 7204C590
.NET Framework 2.0:
testString = (string)o;
0000007c test ebx,ebx
0000007e je 0000009A
00000080 cmp dword ptr [ebx],788ED668h
00000086 jne 0000008C
00000088 mov eax,ebx
0000008a jmp 00000098
0000008c mov edx,ebx
0000008e mov ecx,788ED668h
00000093 call 75621D76
00000098 jmp 0000009C
0000009a mov eax,ebx
0000009c mov esi,dword ptr [ebp-40h]
0000009f lea edx,[esi+00000104h]
000000a5 call 7561BBB0
在这里大家可以清楚地看到，.NET Framework 1.1 仅仅是简单的将强制转换交给一个函数来处理（红色部分），但是2.0则首先进行了一些简单的处理，例如先判断是否是null（test ebx, ebx），以及判断o是否就是恰好string类型而不是string的子类型（cmp dword ptr [ebx], 788ED668h）。当然了，string是一个sealed的类型所以明显不可能有子类型，如果我要求强制转换成Form呢？如果这两项都失败了，才会和1.0里面一样调用一个函数来判断。所调用的函数实际上是将ebx所引用的对象里面的类型向上查找其父类型，看看有没有string类型（788ED668h），可以预见这是一个相对较为耗时的操作。而在我们实际的应用里面，如果进行强制转换通常都是直接转化成他的实际类型的，因此这一小段代码能够较为明显的提高系统的性能。不过这里也可以看到，优化过程还是做的不够，应该将86到8a这三句简化成一句je 0000009A。
我们再来看看ToString的情况。由于ToString是一个virtual的函数，被string类型override了，因此必然需要查v-table来进行正确调用。通过查看.NET Framework 1.1 所JIT出来的代码，可以清楚地看到这一点：
testString = o.ToString();
00000108 mov edi,ebx
0000010a mov ecx,dword ptr [ebp-0Ch]
0000010d mov eax,dword ptr [ecx]
0000010f call dword ptr [eax+28h]
00000112 mov esi,eax
00000114 push esi
00000115 mov ecx,edi
00000117 mov edx,995358h
0000011c call 71E7021D
这里ebx指向object o的类型描述，ebp - 0Ch指向object o对象本身（其实这里的负偏移12个字节就是类型描述，两者实际上是完全紧挨着的），其第一个dword就是string类型本身的数据（不是实例的数据）。我并不是非常清楚里面的一些实现，通过观察，估计可能里面包括了本类型的一些描述，父类型和接口的描述，里面偏移0x28应该就是vtable的实质内容（估计），其第一个就是指向ToString实际函数地址的指针。后面一个调用估计应该是一个赋值调用，和ToString调用可能没有太大的关系。为了证实我的想法，我甚至跟踪到第一个调用内部，发现确实是到了string.ToString()里面（大家可以看Disassembly页的Address下拉框，里面现实的是System.String.ToString），其代码如下：
00000000 push esi
00000001 mov esi,ecx
00000003 mov eax,esi
00000005 pop esi
00000006 ret
分析到这里，我仍然不能够确定为什么ToString比强制转换性能相差10倍的原因。如果非要我估计一下，那么我会这么比较：
强制转换一共经历了：两个“比较+条件转移”，一个寄存器间赋值，一个索引器加偏移到寄存器赋值，一个普通调用（内部经历过程已经在前面分解了），一个赋值调用（内部无法分析）。
ToString一共经历了：5个寄存器间赋值，一个常数到寄存器赋值，两个间接（加偏移）地址到寄存器赋值，一个寄存器压栈，一个寄存器加偏移量间接地址调用（内部已经在前面分解了），以及一个赋值调用（内部无法分析）。
除去无法分析的部分，ToString比强制转换多出将近一倍的汇编指令，并且还包括比较耗时的间接地址赋值调用指令。光是这个差别，估计就应该有至少150%的性能损失。但是现在性能相差接近10倍，难道是仅仅因为那几句间接寻址的指令造成的？那就有点不可思议了。其实我有点怀疑ToString后面第二个调用内部有一些损失性能的指令（也许是多余的指令），如果我们看看.NET 2.0 Release版本的数据，也许是应该这么解释吧？有关这个问题需要做更多的研究……
嗯，今天的Post的正式内容到此结束。PS一下：
1、twodays在cnblogs里面的Post里面回复说：
“o.ToString() 实际上是调用了从object继承出来的ToString()虚函数，这一个虚函数在string类型里面被重写，代码如下：”
不对，因为你的o这会儿本来类型就是object，而不是string，所以他调用的实际上应该是object的ToString方法里面的内容，经过Reflector查看，里面的内容是：
return this.GetType().FullName;
这里我可以明确地告诉你，你错了（包括后面表示赞同的“小新0574”），至于为什么我会另外在一篇Post里面给出解释，因为这两个问题的难度级别相差太大了，在这里写也许很多朋友已经看得迷迷糊糊的了，继续看下去效果不好。
2、我记得有人在上一个Post里面问过as操作性能如何，我也做过试验了，性能没有差别，至少用肉眼观察数据结果是看不出来的。也许在Disassembly层会有细微差别，但是我没有兴趣再研究下去了。
3、有人说自己写的类里面ToString()可能会抛出Exception的问题，其实我是这么认为的。如果你在代码里面抛出Exception的话，那应该是一件相当遗憾的事情。因为ToString()没有任何参数，不可能因为参数问题引起异常。同时ToString函数的含义是，安全的返回关于该实例的信息，因此从感情上来说就不应该出现Exception的情况。很多时候我们就是利用ToString的一些特性来完成一些简单的事情，例如在ListBox里面加入一个不是String的对象，但显示的是用户能够理解的信息，这样用户方便选择，我们则方便编写代码。如果你的类会在ToString里面抛出异常，那么整个程序就会因此而不稳定。总之我认为在ToString() 里面抛出异常并不是这个函数存在的本意。
假设我有一个object类型的变量o，需要转化成string类型的变量s。那么请问下列方式当中的那一个方案更加有效率：
1、
s = (string) o; 2、
s = o.ToString(); 相关提示： 1、(string) 强制转换对应一句IL语句castclass，在IL中大概表现为： L_0019: ldloc.0 L_001a: castclass string L_001f: stfld string WindowsApplication1.Form1:: testString这样的形势，注意强制转换只增加L_001a这一句IL语句。 2、o.ToString() 实际上是调用了从object继承出来的ToString()虚函数，这一个虚函数在string类型里面被重写，代码如下：
public override string ToString()
{
return this;
} | 如果效率有差别，差别是多大呢？答案在于实践当中。
今天在做一个实验，突然发现一个不寻常的地方：VS2k5 C# 在编译for循环的时候，IL代码跟以前的方式不一样：
L_0029: ldloc.1
L_002a: ldc.i4 100000000
L_002f: clt
L_0031: stloc.s flag1
L_0033: ldloc.s flag1
L_0035: brtrue.s L_0018
这个for循环的C#语句大致为
for (num1 = 0; num1 < 100000000; num1++)
上面IL里面所显示的正是比较num1是否小于100000000的片断，如果在VS2k3里面，则应该编译成：
L_0029: ldloc.1
L_002a: ldc.i4 100000000
L_002f: blt.s L_0018
仔细再研究一下，发现这个变化只在Debug模式里面出现，也就是说这个变化并不是为了效率考虑的。但是原来的方式也能够比较容易的进行调试跟踪，实在搞不清楚为什么要用clt的方式。更加奇怪的是，在clt比较得出结果之后，还要弦弹出来保存到一个flag1的本地变量里面，然后再重新压栈。想了想，可能还是为了“更”方便的进行调适吧：比如说在IL级别进行调试的时候，可能看堆栈是不方便的，同时看两个变量的关系也是让人眼花的（n位数字比较，光是对齐数字就头痛了）。通过这样的IL变化，我们可以简单的看看flag1到底是什么结果。如果发现不对了，还可以在跳转之前把当前执行语句移到其他地方，或者修改转移条件，甚至不需要修改循环变量。这些在以前估计是不可能的，因为blt直接就判断并跳走了，就算可以修改转移条件，也必然影响循环变量i。如果考虑的更深入一点，我们可以简单的修改一条IL指令，使得flag恒为true或者false，强制控制流按照我们希望的方式去走，但是又不影响所有源代码里面的变量，这样子也许能够轻易的进行全覆盖的单元测试。不过这么强的能力目前好像还没有看到C#里面有相应的操作项，所以一切都只是猜测。真正的原因也许需要查找更多的资料，或者问问C#项目组的人员才知道了。
顺便说一下，最新版本的Reflector好像有点奇怪，在同一个函数里面IL结构完全一样的两个循环，前面一个会被翻译成while，后面一个会被翻译成for，也不知道是从什么时候开始的。因为这个是在看VS2k5 C#的Release模式编译出来的程序发现的，我一开始还以为这是VS2k5的优化成果呢……
前一段时间 mvm写了一个 记录键盘敲击情况的程序， Post里面提到有两个特殊的全局钩子可以在.NET里面钩上。今天终于有幸把mvm的程序下载下来，然后偷偷的用Reflector去翻看了一下。哦，原来说的是SetWindowsHookEx这个东西，之前没有认真看Post…… 然后我就查了一下这个函数，不查不要紧，查了之后发现这里面有一张表：
| Hook |
Scope |
| WH_CALLWNDPROC |
Thread or global |
| WH_CALLWNDPROCRET |
Thread or global |
| WH_CBT |
Thread or global |
| WH_DEBUG |
Thread or global |
| WH_FOREGROUNDIDLE |
Thread or global |
| WH_GETMESSAGE |
Thread or global |
| WH_JOURNALPLAYBACK |
Global only |
| WH_JOURNALRECORD |
Global only |
| WH_KEYBOARD |
Thread or global |
| WH_KEYBOARD_LL |
Global only |
| WH_MOUSE |
Thread or global |
| WH_MOUSE_LL |
Global only |
| WH_MSGFILTER |
Thread or global |
| WH_SHELL |
Thread or global |
| WH_SYSMSGFILTER |
Global only | Thread/Global是什么回事我一下子也没反应过来，倒是另外两个东西把我吸引住了：WH_JOURNALPLAYBACK/WH_JOURNALRECORD。我就记得以前在什么地方看见过这个东西的，而且是在.NET里面！后来看了这两个钩子的解释，我才发现原来说的是所有输入的记录和回放，想起来好像是一个用来录制和播放“宏”的什么软件里面看到的。同时我在这两个钩子的Remark里面找到这么一段话： Unlike most other global hook procedures, the JournalRecordProc and JournalPlaybackProc hook procedures are always called in the context of the thread that set the hook.
也就是说这两个钩子也可以被钩住，证明我之前的印象应该没有错，确实在什么地方看到一个录制和播放宏的.NET程序用到了这两个钩子。那么到底为什么这两个钩子就可以用了呢（包括mvm提到的那两个）？上面那句话说了，他们跟其他大部分的钩子不一样，他们是在设置钩子所在的上下文（也就应该是进程/线程）里面执行，而不是引发该调用的上下文（其他程序）。 想到这里就不免觉得奇怪，凭什么这四个钩子就对.NET这么亲切呢？为什么其他的全局钩子就不行？都是全局的呀！我想答案可能在LowLevelKeyboardProc的Remark里面：
This hook is called in the context of the thread that installed it. The call is made by sending a message to the thread that installed the hook. Therefore, the thread that installed the hook must have a message loop.
原来是发送消息给设置全局钩子的进程，怪不得对.NET的程序特别亲切了。不过在JournalRecordProc和JournalPlaybackProc里面都没有说到是通过消息来传递的，更没有像上面提到的那样，需要有一个message loop。不过事实上我想无论如何这两个钩子都需要有消息循环，原因很简单，系统在用户按下：Ctrl-Break/Ctrl-Alt-Del/Ctrl-ESC三者当中任意一个的时候，就会给应用程序发送一个WM_CANCELJOURNAL的消息，也许因为这样默认客户程序必须有一个消息循环吧……（还是不敢确定）
但是问题又来了，为什么其他的钩子就不能够用同样的方法呢？基于安全或者性能的考虑？这个我暂时就不太清楚了。此外，我开始还以为WH_SYSMSGFILTER也是可以在.NET里面设置的，但是详细一看发现原来不是，看来.NET里面能够使用的全局钩子也就这四个了。
前一段时间看到 博客堂上面的 mvm用纯.NET写了一个有趣的程序，用来记录 敲击键盘次数，当时就非常感兴趣。不过可惜这边的破烂蓝波速度质量奇差，当时网络时断时续无法下载，后来有机会 下载了，却连接失效了。所以一直就没有机会看看原程序，家伙都准备好了——Refactor，既然mvm都说了可以disassemble……可惜啊可惜，后来就一直没有关注了。 今天晚上发飚，突然想起来 mvm说我介绍的 这个代码着色器有问题， 说不能够正确处理空格，今天我突然想到原来是博客堂那边的.TEXT有点问题，如果拷贝上去的内容有空格，是不会自动转换成 的，同时也不接受空格，会出错，于是就让mvm以为是语法着色器的问题。于是我就想找mvm的那个Post，re他让他来博客源申请一个号，这样就可以用博客源的编辑器来编辑，编辑好了再转贴到博客堂就不会出问题了。 没想到那篇文章还没有找到，却又重新注意上那篇键盘计数器的Post，发现有40多个Reply，于是进去看看有什么新鲜说法。结果发现有人问 floating窗口怎么做，嘿嘿，不就是floating嘛，拿手好戏……于是干脆忘了原来的想法，改变目标，把我的方法贡献出来给大家：
private const int WM_NCHITTEST = 0x0084;
private readonly IntPtr HT_CAPTION = new IntPtr(2);
protected override void WndProc(ref Message m)
{
if (m.Msg == WM_NCHITTEST)
{
m.Result = HT_CAPTION;
}
else
{
base.WndProc(ref m);
}
}
是不是很简单呢？呵呵，实际上在WinUser.h里面还有好多关于HITTEST的返回值的定义，如果有兴趣的话可以做一个不规则的窗口出来，其实还是相当容易的。至少在要求整个窗口任何部分点击之后都能够移动窗口，代码就比 mvm提供的方法要“简单”多了。（呵呵，mvm的方法其实也挺简单的，至少不需要知道什么消息机制、消息代码等比较啰嗦的东西，以前VB3的时候我就是这么干的。）当然这里涉及了一些CLR以外的知识，可以说并不是非常纯正的CLR解决方案。不过这里也没有使用到任何.NET Framework以外的东西，甚至没有P/Invoke，所以还是相当pure的。有兴趣的话还可以试一下值为-1的Transparent，为0的NoWhere，为3的SysMenu，为20的Close等等，写出来的窗口绝对有着“莫名其妙”的行为，好玩着呢。（不怕死的还可以试一下-2 —— Error，我怕，没试过） P.S.: WinUser.h可以在你的Vs.net安装目录下面的VC7\PlatformSDK\Include里面找到，如果你的VC安装全了的话。比如说： C:\Program Files\Microsoft Visual Studio 2003\Vc7\PlatformSDK\Include\WinUser.h P.S.S.: 今天晚上继续发飚，也许还会有第5、第6篇文章……好戏不是天天有，但今天连台。
原来 Terrarium 1.2 已经发布了，而且还是几个月之前的事情了…… 具体可以到这里下载： http://www.terrariumgame.net不过目前只有Client版本，Server版本没有发布。之前听说连同源代码发布，结果还是没有发布，看来还要等上一段时间了。着一个版本还不是TerrariumII，至少并没有太多大的改进。唯一一个比较大的改进，我觉得就是终于实现了很久以前就计划的“瘟疫”——其实也就是根据某个物种的数量（包括在整个世界中所占的比例）来随机杀死一定数量的动物。如果我没有估计错误的话，这“瘟疫”对于某个个体来说没有前兆，没有规律，没有传染，没有异常行为。它仅仅为了达到生态平衡而设计出来的，虽然让我感到有点不真实，不过从效果上面看来还是比较有效的。记得以前某个物种如果写得太好了，就会出现整个屏幕到处都是这个物种的生物，密度越来越大，逐渐就会挤占其他生物的生存空间，甚至连走路的通道都没有了。这一次的版本经过我大概三个小时的连续运行，发现生物密度被保持的比较好。唯一比较可惜的是，地图的大小还是比较小。而且似乎还有很多的Bug，包括地图大小没有办法修改。（就是Settings->Performans）  想起来那个游戏计划，几乎瘫痪了几个月了……
Ninputer问我这个是干什么的。实际上很多人都问过我这个问题，甚至dudu也问过，甚至还有人因此对这个东西有误会。这个怪我，没有说清楚。今天我就来给大家说明白这个事情。
这个NfaGen2是用来产生复杂正则表达式的，比如如果我在NfaGen2里面这么写：
ws:\s
#_SemiColon:;
#_IdHead:a-zA-Z_
#_IdTail:0-9<IdHead>
_Id:<IdHead><IdTail:any>
Type:<Id>
Name:<Id>
SimpleDefine:<Type><ws:many><Name><SemiColon>
那么SimpleDefine就会生成：
(?<SimpleDefine>(?<Type>[a-zA-Z_][0-9a-zA-Z]*)\s+(?<Name>[a-zA-Z_][0-9a-zA-Z]*))
你觉得是上面那种写法(NfaGen2)比较清晰呢，还是下面这种写法(Regex)清晰？我觉得如果我看到
SimpleDefine:<Type><ws:many><Name><SemiColon>
我就知道SimpleDefine匹配的是一个类似
类型 名称;
这样的字符串，至于类型（Type）是什么东西，我再找Type的定义好了。现在给出的这个例子已经足够简单了，如果我们需要产生比较复杂的正则表达式的时候，区别就更大了。
如果让你直接看或者写标准的正则表达式，估计光是括号对齐就已经让你头痛不已，甚至有时候你需要搞清楚某一个“捕获组”到底捕获了一些什么，这个时候会非常头痛。如果这个表达式本身需要匹配各种括号，那就更加麻烦了，比如我要匹配类似(a+(a+a)+(a))这样的表达式，你觉得用Regex要怎么写呢？
(?>(?<=\(|[+]|\A)(?<left>\()(?=[a-zA-Z_]|\()|(?<=[0-9a-zA-Z_]|\))(?<right-left>\))(?=[+]|\)|\z)|(?<=\(|[+]|\A)(?<var>(?<id>[a-zA-Z_](?:[0-9a-zA-Z_])*))(?=\)|[+]|\z)|(?<=\)|[0-9a-zA-Z_])(?<operator>[+])(?=\(|[a-zA-Z_]))+
如果我不告诉你这个正则表达式就是用来匹配这样的字符串的，你自己能够看得懂这个表达式的作用吗？如果你声称能够看得懂，我再来问你，你说说看捕获组left捕获的内容是什么？var组呢？还有它能够接受那些运算符呢？上述这个式子你如果自己来写的话，要花多少时间才能够写正确呢？如果我现在给你这么一个正则表达式，我要求你修改成能够接受加减乘除这四个运算符，你要花多少时间来修改这样一个表达式呢？
大家再来看看，下面这些就是我用于产生上面那个正则表达式的NfaGen1的源代码（NfaGen2的格式跟这个差不多）：
_root:(?><_leftPart>|<_rightPart>|<_varPart>|<_operatorPart>)+
_leftPart:<_left_start><left><_left_end>
_rightPart:<_right_start><right-left><_right_end>
_varPart:<_var_start><var><_var_end>
_operatorPart:<_operator_start><operator><_operator_end>
_left_start:(?<=<_left>|<_operator>|\A)
left:<_left>
_left_end:(?=<_id_head>|<_left>)
_right_start:(?<=<_id_tail>|<_right>)
right-left:<_right>
_right_end:(?=<_operator>|<_right>|\z)
_var_start:(?<=<_left>|<_operator>|\A)
var:<id>
_var_end:(?=<_right>|<_operator>|\z)
_operator_start:(?<=<_right>|<_id_tail>)
operator:<_operator>
_operator_end:(?=<_left>|<_id_head>)
id:<_id_head><_id_tail>*
_id_head:[a-zA-Z_]
_id_tail:[0-9a-zA-Z_]
_left:\(
_right:\)
_operator:[+]
虽然长了一点，不过看完第一行已经知道大概是什么样的了，而要接受加减乘除四个运算符，只需要修改最下面那一个_operator，变成[-+*/]就可以了。如果你直接修改正则表达式，你可能就会漏掉了检测左括号前面的合法字符的那部分，以及其它的你没有注意到的地方，结果没有办法完全正确的匹配，甚至你不知道问题出在什么地方。
用上述方法定义的时候还有一个好处，就是你可以进行局部的匹配测试，看看局部的正则表达式是否书写正确。例如你可以测试_leftPart，测试的内容包括：
(
(a
a(a
a(+
+(a
+(+
+()
((a
)(a
看看对于左括号的匹配是否正确。如果你直接从标准的正则表达式上面进行类似的提取，是非常困难的一件事情，你必须数一下有多少个"("以及")"，中间还得提防"\("和"\)"这样的被转义了的字符。
上面这个表达式还是很简单的，如果你看看NfaGen2用于进行语法加亮的表达式，你会剧烈的头痛得，像那种几K级别的正则表达式，要对某一个局部提取，进行上面那种局部测试，简直就是异想天开！
好了，说到这里不知道大家是否明白了NfaGen2的作用了呢？如果还是不明白，那表明我表达得不够清晰，或者漏了什么内容，我会再找时间来给大家解释的。谢谢大家的支持。
|
