¿Utilizará goto para causar pérdidas de memoria?

Question

Tengo un programa en el que necesito salir de un gran grupo de bucles anidados. Hasta ahora, la forma en que la mayoría de la gente me ha dicho que lo haga es utilizar un goto feo en mi código.

Ahora, si creo un montón de pila local (creo que es lo que se llaman, si no, me refiero solo a las variables regulares sin usar el nuevo comando) las variables dentro de mis loops y mi programa da con esa declaración if que desencadena el goto, ¿encontraré una pérdida de memoria debido a que mi programa salga de muchos bucles incorrectamente y no limpie las variables locales?

Answer 1

No, no causará una pérdida de memoria . El uso de un goto no significa "salir de bucles de forma incorrecta". Es solo generalmente no se recomienda desde un punto de vista de estructura de código.

Dejando eso de lado, cuando salga del ciclo, las variables locales saldrán del alcance y saldrán de la pila (es decir, se limpiarán) en el proceso.

Answer 2

No, no lo harás.

Sin embargo, asegúrese de que cualquier recurso externo se libere correctamente. Por ejemplo, si abre un archivo, sería posible pasar por alto donde normalmente estaría cerrado.

Answer 3

No. Las variables locales no necesitan ser limpiadas individualmente. Cuando la pila aparece, todas las variables locales desaparecerán junto con ella.

Answer 4

No. Solo puede filtrar la memoria asignada dinámicamente.

Answer 5

Las variables de pila se definen (y asignan) en el momento de ingresar a la función y se eliminan implícitamente en el momento de abandonar la función (ya que todo el registro de la pila de llamadas se elimina). Ninguna cantidad de rebote dentro de la función puede causar ningún tipo de estragos con la memoria que se ha asignado todo el tiempo. Independientemente de la ruta de ejecución que tome a través del código, el registro de la pila aparecerá cuando el control vuelva a la función de llamada y la memoria se liberará.

Answer 6

Goto no siempre es malo, pero en su caso, probablemente no deba usar goto.

Vea ejemplos de buen uso de goto here y here.

Si obtiene una etiqueta que está fuera del alcance, se liberará su objeto en la pila.

Ejemplo:

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

Esto imprimirá:

Dentro de alcance
Un destructor
Después de l etiqueta

Answer 7

No, cualquier variable automática en sus bucles no causará fugas de programación si salta de sus bucles con una instrucción goto.

Answer 8

Las otras respuestas son ciertas ... sin embargo, si tiene que anidar bucles de manera diferente, cuestionaría el diseño que los puso allí. Dividir esa lógica en funciones separadas sería una mejor manera de resolver ese problema.

Billy3

Answer 9

variables de pila (automóviles, no autobots) no son "fugas" igual que las variables asignadas a través de nuevo() o malloc().

En cuanto a la "fealdad" de los gotos, eso es simplemente dogmático. Lee Knuth, era tan brillante como Dijkstra. http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf Evite la programación basada en pasta, pero el uso cuidadoso no se degradará en espaguetis.

A Dijkstra no le agradó porque la mayoría de lo que puede hacer con los gotos se puede hacer con otras técnicas de programación estructuradas y usa menos código, lo que hace al otro menos propenso a errores estructurados.

Comprenda que los gotos no deben ser su primera solución, y no se desvive por usarlos, pero si tiene sentido, no se someta a las moras dogmáticas lench. La declaración de break es simplemente un goto disfrazado, diseñado para casos en los que la estricta adhesión al mandamiento "No usarás gotos" no tenía sentido.

Answer 10

Will backward goto leak resources? O cualquier otro problema potencial con el código a continuación?

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 
     { 

     }