System.WebUI.SumtecReferencedException

一直以来对于什么是AOP没有太深入的概念，直到读完白话面向智能体编程(Agent Oriented Programmig, AOP)[1]之后仍然是没有很深入的认识。也许日后有机会可以深入了解一下，不过今天想将读完该Blog之后的想法记载于此，尽管这样的思考也许挺幼稚的。我对于这些概念没有太多的知识，如果认识有误欢迎指正（通过交流获得知识我觉得是比较有效率的）。

　　首先说明一下，这里的AOP当中的A是Agent，而不是Aspect。虽然目前我没有摸清楚Agent和Aspect的具体差别在哪里，但是可以肯定是有区别的。我想Aspect-OP应该是强调概念与实现的一对一映射，其中单一概念与单一职责原则比较接近，单一实现我暂时找不到比较接近的概念。关于单一实现可以这么说：我们大家都知道MVC的模式、或者一些其它的模式，这些模式其实通过我们口中说出来只是一种想法，或者说是概念。而最终形成代码的才是实现，可是也许会有很多地方会用到MVC，于是对于MVC就会有各种各样的实现。（参见“白话面向智能体编程(Agent Oriented Programmig, AOP)”系列第一篇一开始引用的文章The Ted Neward Challenge (AOP without the buzzwords)[2]，原文的链接无效，这个是google出来的。）引用[2]的作者在文中提到他的研究当中最夸张的情形是，在某个软件当中有一种设计上的概念竟然有10万个（次）实施。（In one system I've studied, the concept:implementation ratio for that single requirement is well in excess of 1:100,000. ）也许这么说还比较难理解，那么我们说说记录异常（to log failures），可能我们会在软件当中随手写道：
MessageBox.Show(ex);
又或者
logfile.WriteLine(ex.Message);
还可能是
myLogger.LogObjectTypeA(ex, objectA);
myLogger.LogObjectTypeB(ex, objectB);
...

　　而事实上将错误记录下来应该是一个问题，或者一种设计上的概念，然而却会在软件当中存在多种不同的实施方案。这种情况对于维护来说可能是一件相当麻烦的事情，因为本来都是同一个概念里面的东西，如果我们因为概念上的问题需要进行更新维护，可能就需要对所有不同的实现进行维护，这将会是一件相当烦人的事情。

　　上面说的是我对Aspect-OP的理解，那么Agent-OP呢？我想“白话面向智能体编程(Agent Oriented Programmig, AOP)”的系列说的还是比较容易理解的，其大意是，我们需要一个跟真实世界更加接近的模型。在Agent-OP里面有很多与OOP不一样的思考方向，例如“有心智”或者说“有目标感”，我想这一点是比较重要的概念。说到OOP我们自然能够想到“对象”，对象的其中一个作用是划定知识界限——什么属于这个对象以内的（比如对象当中的成员），什么属于这个对象以外的。这一概念对于软件界是一个里程碑，应当说是非常有意义的。然而我们也应该能够体会到OOP本身并没有对“驱动力”进行探讨，而事实上目前的软件中的“目标感”更多地是通过下列两种力量驱动的：用户，以及软件背后的设计。

　　用户驱动并没有什么问题，毕竟使用软件的是人。然而通过软件背后的设计来驱动“目标感”，我一直都觉得不是很顺畅——因为这种设计相对来说是静态的，基本上不会根据环境的变化进行相对的调整。比如引用[1]当中提到的一个“鸡块熟了之后捞起来”的例子，也许我们会设计一个ChickenClass和一个ChefClass，ChickenClass有一个事件Cooked告诉ChefObject某个CheckenObject熟了，然后我们就会有下面的代码（C# 2k5）：

CheckenObject.Cooked += ChefObject.Checken_Cooked;

　　这个设计的后果是，不管厨师有多忙，鸡块觉得自己熟了之后就会踢厨师一脚，这时候厨师不管情愿不情愿都得把鸡块捞起来。事实上目前的绝大多数软件中的“厨师”本身根本就没有情愿不情愿想法，只不过是一个奴隶、一个工具而已。有人会说，有的软件中的“厨师”是有心智的，但我想还是与Agent-OP是有区别的，其区别可能在于两个方面：

1、有可能这只是无意识造成的偶然结果；
2、如果是有意识设计出这样的“厨师”，很有可能并非用的Agent-OP的工具。（可能制作的方法并不规范，可能存在一些问题。）

　　也许Agent-OP比较前沿，我自己也说不清楚，换一个面向过程和面向对象来说吧。首先让我们时光倒流20年，假设我们正在使用C语言。我们能够将某些知识限定到某个范围以内吗？我想可以用struct，我们可以设计一个v-table，就像C++背后做的那样。于是我们也一样可以写出类似obj->Member(obj2); 这样的东西来，例如：(obj.v_table[ID_Member])(obj2);

　　可这仍然不是OOP，还有很多的问题是需要有专门的OOP工具才能够解决的。Agent-OP也一样，我们目前如果要制作一个Agent-OP的软件，工具还是相当缺乏的，甚至连人的思想也相当缺乏的。不要忘了，光有OOP的工具，如果使用的人还是以面向过程的方式去思考和设计，最终出来的东西也不是OO的。我想Agent-OP也一样，例如让我来使用Agent-OP的工具兴许就弄不出什么花样来。

　　我为什么会觉得需要Agent-OP呢？因为Agent-OP应该能够提供一定的自适应能力（比如什么时候鸡块算是熟了，什么时候我有时间去处理，以什么样的方式去处理等），有了自适应性才有可能提供自组织能力。没有自组织能力的系统，其整个设计实际上仍然是硬梆梆的。关于这点我们可以用制造行业的发展来做对比：现在的制造业有一种较新的概念叫做“柔性制造”，与此相对的是“刚性制造”。对于“刚性制造”来说，生产线的各个机构的运动方向只能够或者前后或者左右，顶多可以换一个模子或者刀具，因此其任务和目标是定死的。当任务或者目标发生改变的时候，比如原来是造汽车门的，现在要制作飞机机舱门了，那么整个生产线就报废了，对于软件来讲就是需要重新设计。但“柔性制造”就不一样了，生产线上的工作机构有许多的自由度，要制作什么完全依靠工控程序的控制，因此面对任务和目标的变化，只需要更换工控程序就可以了。对于软件来说，我们也希望能够仅仅替换某一个很小的“智能部件”，就能够在一定范围内改变任务和目标，因为我们都知道软件的需求（也就是任务和目标）的改变往往是代价非常高的。要达到这一目的，“智能部件”必须能够自行适应其外部的系统状态，或者说能够与系统的其它部分自行组织起来。要做到所有这些，以目前的技术条件看起来是相当困难的。

　　说到这里，也许已经看到我对于Agent-OP的理解跟引文[1]中所述的有一定的出入了。正是因为这些出入，我对于原文的某些观点有一些不同意之处，且容我细细说来：

痒处一：OO并没有对现实世界中的实体加以区分。
　　引文[1]的作者认为需要区分“发票”和“员工”，因为“发票”是没有智能的死物，而“员工”是有智能的活物。死物只是被动的接受各种的操作，而活物除了会主动的进行操作之外，还有可能主动的进行调整，甚至是拒绝操作。
　　然而我认为现实世界如此，并不代表虚拟的世界也必须如此。难道虚拟世界就不能够如同动画片或者科幻片中的想象那样，存在具有思想感情的“发票”吗？更尖锐一点说“机器（人）”是死物呢，还是活物？反过来也一样，“员工”一定是活物吗？还是那个例子，如果你家里有一个机器人员工你打算怎么办？当然，这样的例子比较变态，但是我想从中说明，虚拟世界的对象是否应该具有心智，并不取决于现实世界中影射的对象是否具有心智。而对于作者说的“可以引入计时器或者多线程，但是总是因为与现实不符而不爽”是非常认同的，然而实际上引起这一问题的实质并非在于虚拟对象与现实对象在心智上的映射不能相对应。关于这一问题，我想在后面的条目中会有所揭示。

痒处二：同步和异步被人为地剥离。
　　因为[1]的作者认为，操作者不应该关心到底是使用同步方式还是异步方式，这个问题应该由被操作对象自行决定。
　　然而我觉得这种想法可能存在问题。
　　问题一：被操作对象必须具有心智才能够决定到到底是同步还是异步，假如被操作对象是一张发票，那么这如何进行解释？
　　问题二：事实上现实世界绝大多数情况下都是以异步的方式进行的。老师说“同学们翻开第78页”，然后无论同学们翻不翻书，老师都会继续说下去。上司向下属布置任务，也只有上司在不停的说，决不会每一句话都等下属确认“明白”之后才说下一句话。此外，现实世界如果需要进行同步，通常都是双方都有决定权的。老师说“同学们翻开第78页”，如果哪个同学还没有翻到那一页，深怕漏听了哪一句话，肯定得说“老师等一下，我还没有翻到那一页”。（高考复习给出重点复习内容的时候大家没少遇到这种情况吧，大学期末考试老师给出考点的时候也没有少遇到这种情况吧？）而上司如果深怕下属没有想明白某句话的时候，也会问下属“明白了没有？”或者“有没有什么问题？”，等到下属说“明白”或者“没问题”之后才继续说下去。
　　问题三：其实现实世界当中的同步是通过等待他人“虚拟”出来的概念，正如计算机世界的异步是通过独立线程“虚拟”出来的概念。只不过目前对于计算机世界来说，被调用方向要主动要求调用方等待（或者不要等待）是一件较为困难的事情。除了软件方法当中缺乏这样的概念和工具之外，这也对调用方提出了更高的知识要求：原来只要知道“同步”（或者“异步”）调用对方的处理方法就能够完成工作，而现在却还需要知道如果对方要求“异步”（或者“同步”）的话怎么办。较为简单的办法是调用方继续假装一切按照同步的方式进行，但是这样的话有何意义呢？反过来也有类似的问题。当然，问题总是能够解决的，只是这种解决所付出的代价和获得的回报之间是否存在利益。很明显，以目前的技术条件不可能在所有的操作面前我们都能够从中获利。（假如是工作流引擎的话，可能性会比较大，毕竟工作流比较贴近现实，异步的操作实际上比较多。）

痒处三：无法自然地模拟现实世界中的感知能力（Sensebility）
　　引文[1]作者认为，目前软件的问题在于缺乏感知能力。例如：“如果鸡块的颜色由肉色转变至金黄色，俺就必须做出相应的操作/处理：把鸡块捞出锅来。”而目前的软件设计更多的是有鸡块引发“熟了”这个事件，然后因为“我”订阅了鸡块的“熟了”事件因而此时被鸡块“踢了一脚”，“我”就立刻按照程序把鸡块捞出来。从这种描述看来，“我”并不是通过观察“鸡块”的颜色是否变黄来判断“鸡块”是否“熟了”。
　　而我认为这种想法也很有问题（也许只是作者的例子举的不恰当）。

　　首先，这里并不是没有进行观察，只是观察的是一个现实世界当中不存在的观察量。假如我换一种方法，变成订阅“鸡块”的颜色值变化事件（BackColorChanged），当颜色值发生改变的时候鸡块就引发事件。而如果“我”发现“鸡块”的颜色偏黄到一定的程度（(BackColor.R + BackColor.G)/BackColor.B > threashold），“我”就捞起“鸡块”。怎么样，现在改成观察鸡块是否变黄来决定鸡块是否该捞起来了吧？可是你一定还是觉得不对，因为根本原因不在观察什么，而在于“我”被鸡块“踢了一脚”。
　　在现实世界如果你被鸡块踢了一脚告诉你该捞起来了，你也许会觉得不爽，但在计算机的世界未必如此。假如你给KFC开发一个自动捞鸡块的机器，客户一定期望着鸡块熟了的时候能够踢机器一脚，让它立刻把鸡块捞起来。而且在可以有直接的、积极的、主动的方法进行沟通的情况下，为什么非得要屏蔽这一方法，舍近求远舍本求末的采取间接的、消极的、被动的方法进行沟通呢？现实世界的鸡块之所以不会再熟了的时候踢你一脚，是因为现实世界的鸡块确实是死物，并不是你不期待它会踢你一脚。如果鸡块炸糊了，你会感到更不爽的。再举一个例子，为什么现实世界的烧水的水壶还带一个“哨子”，水烧开了就叫呢？就是因为实际上人们期望水烧开的时候水会“踢”你一脚，让你赶紧把火给关了。虽然水是死的，我们却希望让它活过来，不是吗？
　　因此我觉得这里是本末倒置了：很多时候我们之所以希望贴近现实，只是因为我们期望它能够跟现实当中那样方便；而如果现实当中的情况不符合我们的期望的时候，我们就不应该按照现实中的那样去做。

　　其次，这个例子之所以能够引起我们的感触，是因为我们需要对“鸡块”的颜色做出判断，但是计算机竟然不需要。而且现实当中每个人对于“鸡块”的颜色变成什么样了才算熟，并没有一致的答案。其根本原因在于现实世界有很多很多的“量”，大体可以分为两种“可观测量”和“不可观测量”。鸡块的便面颜色属于可观测量，是否熟了属于不可观测量。于是我们会面对根据可观测量猜测不可观测量的问题，而每个人之所以会有不同的答案，原因在于猜测过程当中需要用到很多知识，也包括经验。每个人的知识不同，因此猜测的准确度就不可能相同。在这个例子当中，我们的根本任务是根据不可观测量的变化作为进一步操作的依据，也就是说“如果鸡块熟了，就捞起来”。但是“熟了”这个量不可直接测得，因此只好根据可观测量猜测不可观测量的值。可是如果现在给你一个神奇设备，能够直接告诉你鸡块“熟了”，你还会多此一举去判断鸡块的颜色吗？也许会看一下，以防设备坏了不知道，但是如果设备没坏，我想你是不会费神去根据鸡块颜色来判断鸡块是否熟了。
　　简而言之，如果软件中的鸡块能够提供“熟了”的信息，就不应该屏蔽它然后提供“表面颜色”来让厨师猜测，此举舍近求远，浪费脑细胞——除非你在设计一款猜谜游戏，玩家扮演的是“厨师”这个角色……
　　当然，从另一个角度看，我们也确实可以看到，现在常见的商业软件方法并没有“不可观测量”这个概念（但是在科学计算里面经常可以看到，不过也不是作为软件设计概念存在的），更不要说对此有什么解决方案了。如果我们正在设计的部分属于跟现实世界进行互动的部分，那么这一概念是不能够忽略的。对于工作流引擎来说就是这样的一种情况——什么时候属于“完成”了或者“出状况”了，有的时候并没有一个直接可观测得标志能够表明这一情况。如果软件足够智能，就应该考虑根据可观测量对不可观测量进行猜测的能力。

　　最后，作者在文中接近最后所提出的一个说法，我想要提出比较强烈的异议。作者说：
　　“在现有的delegate解决方案中，我们只能针对实例（Instance）进行注册，而不可以针对类型（Type）进行注册。……如果能够提供针对类型的注册机制，只要将俺的后续操作到鸡块类上注册一次，在感知范围内的所有鸡块，管他是十块还是二十块，都能被俺感知到颜色上的变化并执行正确的后续操作，这样会来的更简洁，更自然。”
　　首先，至少在.NET里面类型上面完全可以有delegate/event，比如说AppDomain.UnhandledExceptions就是类型上的事件，针对类型进行注册在.NET里面是完全可能的，并且不难看到。因此说这个并不是OO的问题，顶多属于某种语言内部的问题。其次，这种通过注册到某个类上面来对所有正在炸的鸡块进行观测，是一种很不明智的做法。因为这不属于类型上面的知识范畴，而应该属于某个锅以内的鸡块集合的范畴。假如现在有三个锅正在炸鸡块，那引文[1]作者的想法可就得挨屁股了。

　　不过话又说回来了，我非常认同作者说的其中一点，那就是：不应该由鸡块决定什么时候被捞起来，而应该由厨师来决定，尤其是要根据他自己所处环境的其他状况来决定——海啸来了还管鸡块干什么，赶紧逃命吧！这是目前的模型所欠缺的，不管厨师的情况如何，鸡块熟了都会引起厨师的相应动作。当然了，你可以这么写：

PriorityQueue needToBeFishedOut = new PriorityQueue();

private void Chef_ChickenCooked(object sender, EventArg e)
{
    needToBeFishedOut.Enqueue(sender);
    needToBeFishedOut.BringUpPriority();
}

然后再弄一个线程或者计时器进行相应的处理。然而正如作者所言，很不爽。好比让你用C来写真正OO的程序，用asm来写网页，或者用小刀来刻硬盘。工具不对，做起来既费劲又不规范，因此Agent-OP确实需要发展。

最后，我还是要补充一句，OOP和Agent-OP属于不同层次的概念，因此Agent-OP和OOP的关系更像是Class和Method的关系，前者不可能替代后者，并且应该在后者的基础上发展。（我甚至觉得Agent-OP已经不属于语言范畴的东西了，不一定会出现像OO出现之后，世界上所有语言都向OO的方向发展那样的壮观场景了。）

首先感谢拓荒者为我们提供了错误样本。其次感谢kaneboy把这个错误报告上去，并告诉我们这却是一个Bug，并且知道这个Bug在桌面上的所有x86版本的.NET上面都存在。这个Bug预计在下一个版本的.NET 2.0 beta里面得到修正，已有版本的SP就不知道什么时候才有了……这个Bug到底有多严重，见仁见智吧，不想在这里做评论。这里写一下只是让闲得无聊的人见识一下这个奇异现象，或者让真的觉得威胁到自己软件安全的人注意一下。
其次希望微软能给我奖金，或者至少稿费。

该错误在一般使用的情况下很少遇到，但在非常特殊的使用方式下才会产生，尤其在您特意使用一些C#的副作用的时候更容易产生。不过如果遇到了，说不定真是会损失惨重。（我个人感觉这种错误跟Intel多年前奔腾芯片的浮点错误非常神似。）

下面是错误重现：

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)替代这一句话，也会引起相同的问题。与此相反的减法操作的问题，原因和解释类似。

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 = 2⁰ + 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所能够改变得了的。

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的问题应该已经讲完了。还有什么疑惑吗？

真正未来的理论是什么，我不知道。但是至少我看到面向接口的设计思想比“面向对象”要更为先进，而目前真正能够这样思考的人远比知道如何封装继承的人要少得多。从这个角度讲，那也算是未来的技术，至少是未来需要普及的技术。（现在COM不就是这样一种思想吗？）

1、读一文件2M大，与读144个共200K文件同速；
2、快排序远比删除要慢（仅供参考）。

一个强制转换快还是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)下面分别测试，测试结果数据如下：

        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;

s = o.ToString();

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的优化成果呢……