使用goto会导致内存泄漏吗？

Question

我有一个程序，需要打破一大堆嵌套的 for 循环。 到目前为止，大多数人告诉我的方法是在代码中使用丑陋的 goto。

现在，如果我在循环中创建一堆本地堆栈（我认为这就是它们的名称，如果不是，我的意思只是常规变量而不使用新命令）变量，并且我的程序命中触发 goto 的 if 语句，由于我的程序不正确地退出许多循环并且没有清理局部变量，我会遇到内存泄漏吗？

Answer 1

不，您不会导致内存泄漏。使用goto并不是“不正确地退出循环”。 从代码结构的角度来看，通常不推荐。

除此之外，当您离开循环时，局部变量将超出范围并在此过程中从堆栈中弹出（即清理）。

Answer 2

堆栈变量（汽车，而不是汽车人）不像通过 new() 或 malloc() 分配的变量那样“泄漏”。

至于 goto 的“丑陋”，这只是教条主义。 读高德纳 (Knuth) 的书，他和迪杰斯特拉 (Dijkstra) 一样才华横溢。 http://pplab.snu.ac.kr/courses/ adv_pl05/papers/p261-knuth.pdf 避免基于面食的编程，但小心使用不会退化为意大利面。

Dijkstra 不喜欢它们，因为用 goto 做的大部分事情都可以用其他结构化编程技术来完成，并且使用更少的代码，因此使其他结构化编程技术不易出错。

明白 goto 不应该是你的第一个解决方案，并且不要不遗余力地使用它们，但如果它有意义，不要屈服于教条主义的暴民。 Break 语句只是一个变相的 goto，专为严格遵守“你不得使用 goto”戒律而没有意义的情况而设计。

Answer 3

堆栈变量在您进入函数时定义（并分配），并在您离开函数时隐式消除（因为整个调用堆栈记录都被弹出）。 函数内部的任何弹跳都不可能对一直分配的内存造成任何破坏。 无论代码采用什么执行路径，当控制权返回到调用函数时，堆栈记录都会弹出，并且内存将被释放。

Answer 4

不可以。您只能泄漏动态分配的内存。

Answer 5

其他答案是正确的......但是，如果您必须以不同的方式嵌套循环，我会质疑将它们放在那里的设计。 将逻辑拆分为单独的函数将是解决此类问题的更好方法。

比利3

Answer 6

Goto 并不总是不好，但就您而言，您可能不应该使用 goto。

请参阅此处和良好使用 goto 的示例="https://stackoverflow.com/questions/788903/valid-use-of-goto-for-error-management-in-c">此处。

如果您转到超出范围的标签，则堆栈上的对象将被释放。

示例：

#include <iostream>
using namespace std;

class A
{
public:
  ~A() 
  {
     cout<<"A destructor"<<endl;
  }
};



int main(int argc, char**argv)
{
  {
    A a;
    cout<<"Inside scope"<<endl;
    goto l;
    cout<<"After l goto"<<endl;
  }

  cout<<"Outside of scope before l label"<<endl;

l:
  cout<<"After l label"<<endl;
  return 0;
}

这将打印：

范围内
析构函数
l 标签后

Answer 7

没有。 局部变量不需要单独清理。 当堆栈弹出时，所有局部变量将随之消失。

Answer 8

不，如果您使用 goto 语句中断循环，循环中的任何自动变量都不会导致编程泄漏。

Answer 9

不，你不会的。

但是，请确保正确释放所有外部资源。 例如，如果您打开一个文件，则可以跳到通常关闭该文件的位置。

Answer 10

向后goto会泄漏资源吗？ 或者下面的代码有任何其他潜在的问题吗？

重新执行：

        try
        {
            //Setup request
            HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);

            ....

            //Get Response
            HttpWebResponse response = (HttpWebResponse)request.GetResponse();

           if(response != HttpStatus.OK && noOfRetries < 3)
            {
                noOfRetries++;
                Thread.Sleep(10 * 1000);


                response.Close();
                goto Reexecute;
            }
            ...

            response.Close();
         }
         catch
         {

         }