无用单元的收集
CLR中的无用单元收集程序监控一个软件的资源，一旦系统中的可用资源减少到了一个极限，发现无用的对象后就会消灭它。无用单元的收集带来的一个好处是你无需担心最常见的循环调用问题，在一个循环调用中，子对象调用父对象，而父对象又调用了子对象。在一个调用调度系统中，循环调用可能使任一对象都不能被释放或消灭，而无用单元收集程序则可以发现这种循环调用，并消灭它，这也意味着释放最近对一个对象的调用无需立即消灭这个对象。
无用单元收集带来的后果是：我们无须再依赖于一个类的Terminate事件。事实上，如果线程被阻塞了，Terminate事件也不可能得到执行，这也就是所谓的不确定性终止，与它相对的是由COM提供的确定性终止。确定性终止的缺乏和由于无用单元收集而引起的对内存单元的重新调度和紧凑在互联网上的新闻组中引起了热烈的讨论。我认为这些限制会引起你的不快，因为你已经习惯了确定性终止，也许你并不依赖于Terminate事件而认为这无关紧要。无用单元收集程序并非是万能的，在使用时仍然会有许多限制。
从引用计数到无用单元收集只是说明Visual Studio.NET的基础架构不再是COM的一部分。在VB.NET中，你仍然可以使用ActiveX服务器、ActiveX控制等COM对象，但必须通过适当的"wrapper"才行。提到"wrapper"这个词，就可能意味着性能上的折扣和执行上的差异。如果要移植一个使用了大量的COM对象的软件，就需要进行很好的测试和规划，甚至重新设计部分代码才能确保移植成功。坦率地说，你会遇上挫折，还记得把VBX向OCX移植的恶梦吗？
在开发语言中的变化还不仅仅局限于架构的变化，这些变化中的大多数都有积极的意义，但我认为并非所有这些变化都是积极的。在过去的VB版本中，你可以用多种不同的方法来完成同一件任务，既没有统一的编码标准也无法执行这么一个标准。微软对VB进行了一些比较显著的改变，以便"净化"这种语言，在大多数情况下，你只有一种方法可以完成某一任务。
首先，向过程的参数传递数据的缺省方法由传递地址（ByRef）改成了传递数值（ByVal），这是其中变化最大的部分，原因是向参数传递地址要比传递数值的风险要大得多，这种风险主要来自调用过程可能在无意间改变参数。当然还可以用地址传送参数，但必须改变新的缺省的调用方法。
其次，抛弃了Set语句。把一个对象的地址传递给一个变量只要用一个等号就可以了，对象与其他的数据类型没有什么区别。这看起来很"酷"，但也有一定的负作用：缺省的属性不能用了。例如，再不能用下面的方式来引用一个属性了：
[责任编辑:editor]
最新相关文章发表评论