c++ - 当操作系统无法分配内存时，使用 STL 的应用程序是否应该容易发生内存泄漏？

Question

我个人不喜欢异常处理。在许多地方，建议不要将捕获异常并继续执行程序作为良好的编程习惯。

但是，由于 STL 容器抛出异常(即 bad_alloc)，除了在我们的代码中包含异常处理 block 之外别无选择。但是在我的应用程序中处理 STL 调用时，我发现很难使应用程序防漏和健壮。

下面的示例代码演示了 STL(具有异常处理)如何导致内存泄漏:

void my_function()
{
    try
    {
        std::vector<int> integers; // It can throw bad_alloc here (1)

        for (int i=0; i<10240; i++)
        {
            int* myintptr = new (std::nothrow) int;
            if (myintptr == NULL) // Memory not allocated. But no exception thrown so I am safe to continue.
                continue;
            *myintptr = i;
            integers.push_back (*myintptr ); // It can throw bad_alloc here (2)
            delete myintptr;
        }
    }
    catch(std::bad_alloc& ba)
    {
        // If it come here after throwing exception at (1) its fine. But if it has thrown exception at (2) then it just leaked memory allocated by new int
    }
}

(当然，这只是简化版本，用于演示大型复杂代码中的类似情况。)

现在，这里可能有一些建议:

<强>1。在最窄的 block 上使用异常处理: 所以这意味着我必须在调用 push_back 周围放置另一个 try..catch。但是，如果我想在每个 STL 调用周围放置 try...catch block ，我的代码会是什么样子？

<强>2。确保您有足够的内存:也可能建议我们不要陷入操作系统无法分配内存的情况。因此，我们可以在继续进行 STL 调用之前主动检查是否有足够的内存可用。但这种策略并不总是奏效。拥有足够的空闲内存并不能保证我们进一步请求分配内存会成功(例如，如果内存碎片化。此外，如果系统上运行着其他占用大量内存的应用程序，那么操作系统可能会发现很难在物理内存中找到用于分配的空间，因此它可能会拒绝该请求。)

所以最后一个大问题是:

我们如何使用 STL 使我们的应用程序健壮(不会崩溃，即使操作系统拒绝内存分配请求也能保持运行)和完整证明(即使有异常也不会泄漏)？

Answer 1

你应该了解 RAII !基本思想是，您永远不会拥有任何不受销毁时清理资源的对象保护的资源。由于每当一个 block 被留下时都会调用局部变量的析构函数(除非使用类似 longjmp() 的东西)这种方法完全自动清理。 RAII 技术部分是为了处理异常而开发的，但即使没有抛出任何异常，我发现这种编程风格也能显着减少资源泄漏。

顺便说一句，您强调的关于在出现异常时不继续的建议绝对是胡说八道!此外，除了可以合理地重新启动操作的少数位置，您可能不会有任何 try/catch block !它们对于处理资源清理当然没有用，主要用于处理实际问题。