Will using goto cause memory leaks?

问题:

I have a program in which i need to break out of a large bunch of nested for loops. So far, the way most people have been telling me to do it is to use an ugly goto in my code.

Now, if i create a bunch of local stack (i think that's what they are called, if not, i mean just regular variables without using the new command) variables inside my loops and my program hits that one if statement that triggers the goto, will i encounter a memory leak due to my program exiting many loops improperly and not cleaning up the local variables?

回答1:

No, you will not cause a memory leak. Using a goto is not "exiting loops improperly." It's just not generally recommended from a code-structure point-of-view.

That aside, when you leave the loop, the local variables will go out of scope and be popped off of the stack (i.e. cleaned up) in the process.

回答2:

Stack variables (autos, not autobots) aren't "leaky" like variables allocated via new() or malloc().

As far as the "uglyness" of gotos that's just dogmatic. Read Knuth, he was just as brilliant as Dijkstra. http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf Avoid pasta based programming, but careful use won't degrade into spaghetti.

Dijkstra didn't like them BECAUSE most of what you can do with gotos can be done with other structured programming techniques and uses less code therefore making the other structured less error prone.

Understand that gotos shouldn't be your first solution, and don't go out of your way to use them, but if it makes sense don't submit to dogmatic lench mobs. The break statement is a just a goto in disguise designed for cases where strict adhearance to the "Thou shalt not use gotos" commandment didn't make sense.

回答3:

No. You can only leak memory that is dynamically allocated.

回答4:

Stack variables are defined (and allocated) the moment you enter the function, and are implicitly eliminated the moment you leave the function (since the entire call stack record is popped away). No amount of bouncing around inside the function can possibly cause any havoc with memory that's been allocated the whole time. Regardless of what execution path you take through the code, the stack record will pop when control returns to the calling function, and the memory will be freed.

回答5:

The other answers are true.... however, if you have to nest loops that differently, I'd question the design that put them there. Splitting up that logic into separate functions would be a better way to solve such a problem.

Billy3

回答6:

Goto is not always bad, but in your case you probably shouldn't be using goto.

See examples of good use of goto here and here.

If you goto a label that is outside of scope your object on the stack will be freed.

Example:

#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;
}

This will print:

Inside scope
A destructor
After l label

回答7:

Nope. Local variables do not need to be individually cleaned up. When the stack pops, all the local variables will go away right along with it.

回答8:

No, any automatic variables in your loops will not cause programming leaks if you break out of your loops with a goto statement.

回答9:

No you will not.

However, make sure that any external resources are properly released. For example, if you opened a file it would be possible to jump past where it would normally be closed.

回答10:

Will backward goto leak resources ? Or any other potential problems with below code ?

Reexecute:

        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
         {

         }