【问题标题】:Why are destructors necessary in C++?为什么在 C++ 中需要析构函数?
【发布时间】:2013-10-14 18:25:52
【问题描述】:

为什么我们必须在c++中使用析构函数来释放内存,

我们可以使用

delete or delete[]   

一个程序用完的内存不是都在程序终止的时候释放的吗?

【问题讨论】:

  • 如果我让你的对象在一个循环中运行,只要程序运行(比如创建绘图对象来刷新我的窗口)?操作系统不需要清理,但很有可能会清理。
  • 没有。当程序终止时,程序正在使用的堆栈上的内存被释放,但是当且仅当使用delete 它时,程序在堆上保留的内存才会被释放。如果你不delete它,你有内存泄漏。
  • 这取决于操作系统,即使大多数操作系统在退出时会释放程序分配的所有内存,但您必须意识到您的程序不是单独运行的,计算机中还有其他人并且资源(内存)是共享的,因此请尝试优化;)
  • 你对析构函数和释放内存有点困惑,它们是两个不同的东西。正常使用时delete会调用析构函数和释放内存,但是你可以不调用析构函数就释放内存,也可以不使用delete调用析构函数。
  • @nhgrif:不,完全不正确,假设你有一个在任何方面都能胜任的操作系统。

标签: c++ memory raii memory-management


【解决方案1】:

通常,仅在程序终止后才恢复内存是不够的。大多数为连续运行而设计的程序需要分配可变大小的临时内存,而该内存的生命周期没有特定的名称。很明显,如果您请求内存并且在很长一段时间内没有返回它,您的程序将耗尽内存,并在请求额外内存时终止。

话虽如此,您可以在不使用 C++ 中的析构函数的情况下通过分配您可以在自动区域中分配的所有内容来走很长的路。您真正需要使用动态内存的唯一时间是对象的生命周期必须超出其分配范围,但即便如此,C++ 容器也会为您处理大部分分配(当然标准容器的实现在很大程度上依赖于C++ 语言的构造函数/析构函数基础结构)。

【讨论】:

    【解决方案2】:

    “我们使用析构函数来释放内存”

    你真正写的是释放函数operator deleteoperator delete[]

    “一个程序用完的内存不是在程序终止的时候全部释放吗?”

    AFAIK 这是特定于操作系统的,但重点不是程序终止后会发生什么。重点是在执行期间会发生什么。有许多应用程序会运行几个小时甚至几周,而内存泄漏可能会在这些应用程序中产生非常不愉快的后果(并不是说内存泄漏不会对其他程序造成不愉快)。

    当您的程序达到不再需要您分配的资源的程度时,您应该尽最大努力使用适当的方式释放它们。一旦你的程序终止:依靠操作系统清理你的烂摊子似乎不是一个好习惯;)

    【讨论】:

    • 依赖一个不会(至少在内存方面)尝试清理你的烂摊子的操作系统同样是不好的做法 :)
    • @DanielFrey:我的经验法则是:我总是清理我造成的混乱,无论环境如何:D
    • 当然,我也是,但遗憾的是不是每个人都这么认为。因此,我希望操作系统成为一个安全网,因为 即使我 也会犯错误:-P
    【解决方案3】:

    如果使用 RAII,则保证会调用析构函数。这并不是说我们必须使用它,但从 RAII 中受益通常是一个好主意,因为它允许自动资源管理。换句话说,如果你的程序写对了,它就不会发生资源或内存泄漏,所以你甚至不必担心。

    这不仅适用于 C++,也适用于支持自动资源管理的其他语言,例如 C#、Java 甚至 C(通过非标准扩展)。

    基本上,你可能需要阅读一些关于 C++ 的书来理解这个概念。我还写了一篇小文章,可能会有帮助,见here

    希望对你有帮助:)

    【讨论】:

      【解决方案4】:

      首先,deletedelete[] 不是析构函数,它们只是调用被删除实例的析构函数(假设它们确实有析构函数)。

      回答你更大的问题:类的析构函数可以做的不仅仅是释放内存。例如,它可能会向另一个程序发出信号,表明它即将关闭连接或其他什么。

      此外,一些程序“永远”运行 - 或至少尽可能长地运行。例如,我开发在服务器上运行的程序,它们(希望)运行一个月。我确实需要尽快释放内存(或其他资源),否则进程会增长并最终在机器内存不足时崩溃。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2020-01-06
        • 1970-01-01
        • 2021-10-09
        • 2010-11-16
        • 2013-05-22
        • 2014-02-02
        • 1970-01-01
        相关资源
        最近更新 更多