细说ＶＢ．ＮＥＴ（中）

细说ＶＢ．ＮＥＴ（中）
源代码网推荐（作者：青苹果工作室编译　2001年03月07日 14:47）
源代码网推荐
源代码网推荐易于反编译的中间语言
源代码网推荐　　无论你用VB、C#或其它.NET语言编写应用程序，VS.NET代码都编译成为中间语言(IL)。当应用程序运行时，一个即时编译器(JITter)处理IL代码并把它编译成为机器语言。这意味着在理论上可能为Windows以外的平台创建.NET运行库，但现在关于类似的事情还没有任何官方消息。中间语言的一个缺陷是：它像VB5以前的VB版本一样，容易被反编译。这种可能性使许多开发者普遍地质疑.NET架构的安全性。
源代码网推荐
源代码网推荐　　CLR在IL层次内外影响代码，对它的修改将使所有使用CLR的语言受益。然而，语言只是和代码如何被解释为IL有关，对特定语言的优化可以根据特定语言的语法来编写，这样在技术上就可能使.NET语言之间的性能差别很小。不管怎样，大体上蓝图是美好的。例如，CLR使VB的调试和监测工具和C#的相应工具相当，它做到了这一点因为它们本来就是相同的工具。
源代码网推荐
源代码网推荐　　CLR提供不平行的跨语言集成，包括跨语言继承代码的能力。所有使用CLR的语言共享一个通用类型系统，它使使用多种语言开发应用程序变得更简单。我不喜欢把 C API 声明翻译成VB里可以使用的形式，所以我很赞赏通用类型系统带来的好处。

源代码网推荐
源代码网推荐　　在CLR中运行的代码被称为被管理代码，被管理代码使用的内存完全由CLR来控制。被管理代码带来很多好处，包括跨语言集成、跨语言异常处理和简化的部件相互作用模型。Visual Basic被限制为只能以被管理代码的方式工作，然而C#拥有跳到非被管理代码的能力(执行到运行库之外)，并能做像指针操作这类事情。这是VB和C#不同等的情况之一。这种能力到底有多重要取决于你想干什么。
源代码网推荐
源代码网推荐　　CLR造成的体系结构差别要比跨语言集成、共享功能和被管理代码等深刻。首先，Visual Studio.NET的支撑结构不是 COM。另外，VB.NET里的所有东西，甚至字符串都是对象。因为这些和其它一些原因，Microsoft改变了支撑结构处理对象的方式。COM实现了一个引用计数方案，这样每次引用一个对象时，计数器递增。当一个对象引用超出作用域或被释放时，计数器递减，当引用计数减少到零时就终止这个对象。Microsoft声称在.NET架构下引用计数的开销太大，以至于不能在 .NET中实现它，所以它放弃了引用计数转而使用垃圾收集。
源代码网推荐
源代码网推荐垃圾收集需要新体系结构
源代码网推荐　　CLR垃圾收集器主要是监视一个程序的资源，当可用资源达到确定的阈值时寻找无用的对象，并在发现它们的时候清除这些对象。垃圾收集的一大好处就是你不再需要担心大多数普通的循环引用，即子对象引用了父对象，然后父对象又引用了子对象。在引用计数方案下，循环引用使两个对象都不能被释放和清除。然而，垃圾收集器会发现循环引用并清除它们。这也意味着释放对象的最后一个引用时不再需要立即清除对象。

源代码网推荐
源代码网推荐　　垃圾收集的一个后果是：你再也不能指望一个类的 Terminate 事件能在适当的时机发出。实际上，如果线程被阻塞，可能根本就不会发出 Terminate 事件。和COM提供的确定化终止相反，它被称为不确定的终止。缺乏确定化终止，以及因为垃圾收集器重新安排并压缩内存从而不能使用指针的事实，在新闻组里激发了一波激烈的辩论。我想这些新限制可能会令你痛恨，因为你要依靠确定化终止；也可能你漠不关心，因为你不依赖 Terminate 事件。垃圾收集并不是万灵药，实现弱引用依然需要做一些考虑。
源代码网推荐
源代码网推荐　　从引用计数到垃圾收集只是 Visual Studio.NET 的支撑结构不是 COM 这个事实的表象之一。你能在VB.NET中使用COM对象，比如说ActiveX服务器或ActiveX控件。然而，你必须通过包装访问这些对象。任何时候听到“包装”这个术语，你应该明白你面对着性能损失，并且对象的行为可能有所不同。如果当计划移植一个使用了大量COM对象的工程，就需要认真地测试和计划，可能需要重新规划应用程序的结构才能移植成功。坦率地说，你要有遭受挫折的准备。还记得从VBX迁移到 OCX的过程吗？我记得，我的精神病医生也记得。我很快就要再去看他了 ;-)