在 VB6/VBA 中是否真的需要对象清除/数组释放(优点/缺点?) [英] Is object clearing/array deallocation really necessary in VB6/VBA (Pros/Cons?)

问题描述

我从使用静态代码分析(尤其是 Aivosto 的项目分析器)中学到的很多关于 VB 的知识.它检查的一件事是您是否清除了所有对象和数组.我以前只是盲目地这样做，因为 PA 是这么说的.但是现在我对 VB 释放资源的方式有了更多的了解，在我看来，这些事情应该是自动发生的.这是 VB6 之前的遗留功能，还是您应该明确将对象设置为空并在数组上使用 Erase 的原因?

A lot of what I have learned about VB I learned from using Static Code Analysis (Particularly Aivosto's Project Analyzer). And one one of things it checks for is whether or not you cleared all objects and arrays. I used to just do this blindly because PA said so. But now that I know a little bit more about the way VB releases resources, it seems to me that these things should be happening automatically. Is this a legacy feature from pre VB6, or is there a reason why you should explicitly set objects back to nothing and use Erase on arrays?

推荐答案

据我所知，这个问题与 VB6(及其前辈)的根源在于 COM 及其引用计数垃圾这一事实有关采集系统.

The problem, as I understand it, has to do with the fact that VB6 (and its predecessors) has its roots in COM, and its reference-counting garbage collection system.

想象一下，例如，您声明了对来自 3rd 方库的对象的引用.该对象有一个 COM 引用计数，用于使其保持活动状态并确定何时应销毁它.当您将其设置为 Nothing 时，它不会被销毁，但是当对象的引用计数达到零时.

Imagine, for instance, that you declare a refernece to an object from a 3rd party library. That object has a COM reference count that is used both to keep it alive and to determine when it should be destroyed. It isn't destroyed when you set it to Nothing, but when the object's reference count reaches zero.

现在，并非所有 COM 组件都是用 Visual Basic 编写的.有些是用 C 或 C++ 编写的.并非所有语言都存在结构化异常处理.因此，如果发生错误，则无法保证对象的引用计数会适当减少，并且已知 COM 对象会比预期的停留时间更长.这本身不是 Visual Basic 的问题.这是一个COM问题.(您可能会注意到，这就是 .NET 不使用引用计数的原因.)

Now, not all COM components were written in Visual Basic. Some were written in C or C++. Structured exception handling didn't exist across all languages. So if an error occurred, the reference count on the object was not guaranteed to be properly reduced, and COM objects were known to hang around longer than they were intended to. This wasn't a problem with Visual Basic, per se. It was a COM problem. (And that, you might note, is why .NET doesn't use reference counting.)

这就是为什么 Visual Basic 开发人员对在退出例程之前释放对象引用非常着迷的原因.您根本不知道您正在分配的组件在后台创建了什么.但是当你释放对它的引用时，你至少释放了对它的引用计数.它几乎成了一种宗教咒语.声明、使用、释放.这是 COM 的做事方式.

That's why Visual Basic developers became obsessive about releasing object references prior to exiting routines. You simply don't know what a component you're allocating is creating under the hood. But when you release your reference to it, you're at least releasing your reference count to it. It became almost a religious mantra. Declare, use, release. It was the COM way of doing things.

当然，Visual Basic 在取消引用我在堆栈上声明的变量方面可能会更好或更快.但是该死的，我希望这些物体被释放是显而易见的.当您试图追踪内存泄漏时，一点保证大有帮助.

Sure, Visual Basic might be better or faster at dereferencing variables I declared on the stack. But dammit, I want it to be OBVIOUS that those objects were released. A little assurance goes a long way when you're trying to track down a memory leak.

这篇关于在 VB6/VBA 中是否真的需要对象清除/数组释放(优点/缺点?)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！