当用户控件正在处置时删除处理程序

发布于 2024-11-27 20:30:05 字数 510 浏览 2 评论 0原文

哪一个是正确的?

这一个:

protected override void Dispose(bool disposing)
{
    if (disposing && (components != null))
    {
        this.ctlRBContent1_GetBuildName -= _ctlBottom.GetBuildName;
        components.Dispose();
    }
    base.Dispose(disposing);
}

OR

这一个:

~ ctlRemoteBuildContent1()
{
    this.ctlRBContent1_GetBuildName -= _ctlBottom.GetBuildName;
}

我尝试切换这两个功能。当我进行 UserControl 处理时,它没有跳到切换行:/

Which one is the right one?

This one:

protected override void Dispose(bool disposing)
{
    if (disposing && (components != null))
    {
        this.ctlRBContent1_GetBuildName -= _ctlBottom.GetBuildName;
        components.Dispose();
    }
    base.Dispose(disposing);
}

OR

This one:

~ ctlRemoteBuildContent1()
{
    this.ctlRBContent1_GetBuildName -= _ctlBottom.GetBuildName;
}

I tried to toggle this 2 functions. When I did UserControl disposing, it didn't jump into the toggle line :/

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

一个人的旅程 2024-12-04 20:30:05

如果您在析构函数中进行清理,则无法保证析构函数何时运行。具有析构函数的对象还需要垃圾收集器处理更多工作。因此,最好实现 IDisposable,这是您的第一个示例。

请注意,您的代码片段并未完全实现推荐的 IDisposable 模式。请参阅这篇文章以获得完整的解释:

http ://www.csharphelp.com/2010/02/c-garbage-collecting-destructors-versus-dispose/

在您的代码片段中,如果出于某种原因components 为空,您不会删除事件处理程序。对 components 的空检查只能用于保护 components.Dispose() 调用。

protected override void Dispose(bool disposing)
{
    if (disposing)
    {
        this.ctlRBContent1_GetBuildName -= _ctlBottom.GetBuildName;
        if (components != null)
        {
            components.Dispose();
        }
    }
    base.Dispose(disposing);
}

If you clean up in a destructor, there's no guarantee as to when the destructor will be run. Objects with a destructor also require more work for the garbage collector to handle. It's preferable therefore to implement IDisposable, which is your first example.

Note that your code snippet does not fully implement the recommended IDisposable pattern. Please see this article for a good and complete explanation:

http://www.csharphelp.com/2010/02/c-garbage-collecting-destructors-versus-dispose/

In your code snippet, if for some reason components is null, you would not remove the event handler. The null check for components should only be done to protect the components.Dispose() call.

protected override void Dispose(bool disposing)
{
    if (disposing)
    {
        this.ctlRBContent1_GetBuildName -= _ctlBottom.GetBuildName;
        if (components != null)
        {
            components.Dispose();
        }
    }
    base.Dispose(disposing);
}
葮薆情 2024-12-04 20:30:05

第二位代码由终结器调用,这意味着您将无法知道何时调用它(取决于垃圾收集器何时运行)。理想情况下,您希望尽快释放资源,通常是在 Dispose() 中。所以这里使用 dispose 模式。

您为什么要在此处取消订阅该活动?它包含什么?

The second bit of code is called by the finalizer, which means you won't be able to tell when this is called (depends on when the garbage collector runs). Ideally you want to free your resources as soon as possible, typically in a Dispose(). So use the dispose pattern here.

Why do you want to unsubscribe that event here? What does it contain?

迟月 2024-12-04 20:30:05

哪一个是正确的?

一个有点令人讨厌的答案是“两者”;-) ...

理想情况下,您希望在 Dispose 方法中进行整理,以便可以尽快执行,但在某些情况下,调用整理代码也很重要从析构函数作为备份,以防对象在未处置的情况下被使用(...我想这取决于您认为这可能的可能性有多大!?)

处置模式(在其他答案中提到)提供了一种方法无需重复代码即可实现此功能在 dispose 和 destructor 之间,并使用 GC.SupressFinalize 确保在整理完成后对象的垃圾收集不会受到不必要的阻碍。

Which one is the right one?

A slightly obnoxious answer is "both" ;-) ...

Ideally you want the tidying up to happen in the Dispose method so it can be performed as soon as possible, but in some situations it's important to also have the tidy up code called from the destructor as a back-up in case an object gets used without being disposed (...I guess it depends on how likely you think this could be!?)

The dispose pattern (mentioned in the other answers) provides a way of implementing this without code duplication between the dispose and destructor, and with the GC.SupressFinalize makes sure the object's garbage collection doesn't get held up unnecessarily if the tidy up has been done.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文