गोटो कारण मेमोरी लीक का उपयोग करेगा?

Question

मेरे पास एक ऐसा कार्यक्रम है जिसमें मुझे लूप के लिए नेस्टेड के बड़े समूह से बाहर निकलने की आवश्यकता है। अब तक, जिस तरह से ज्यादातर लोग मुझे यह करने के लिए कह रहे हैं, मेरे कोड में एक बदसूरत गोटो का उपयोग करना है।

अब, अगर मैं स्थानीय ढेर का एक समूह बनाने के (मुझे लगता है कि है कि वे क्या कहा जाता है यदि नहीं, तो मैं नए आदेश का उपयोग कर के बिना बस नियमित चर मतलब है) मेरी छोरों के अंदर चर और मेरा कार्यक्रम हिट है कि एक बयान है कि अगर गेटो को ट्रिगर करता है, क्या मुझे अपने प्रोग्राम के कारण कई लूपों को अनुचित तरीके से निकालने और स्थानीय चर की सफाई नहीं करने के कारण मेमोरी लीक का सामना करना पड़ेगा?

Answer 1

नहीं, आप एक स्मृति रिसाव का कारण नहीं बनेगा ।goto का उपयोग करना "अनुचित तरीके से बाहर निकलना" नहीं है। यह केवल है जो आमतौर पर कोड-संरचना बिंदु-दृश्य से की अनुशंसा नहीं करता है।

उस तरफ, जब आप लूप छोड़ते हैं, तो स्थानीय चर स्कोप से बाहर हो जाएंगे और प्रक्रिया में ढेर (यानी साफ हो जाएंगे) से पॉप हो जाएंगे।

Answer 2

नहीं आप नहीं करेंगे।

हालांकि, सुनिश्चित करें कि कोई बाहरी संसाधन ठीक से जारी किया गया है। उदाहरण के लिए, यदि आपने एक फ़ाइल खोली है तो इसे पिछली बार कूदना संभव होगा जहां इसे सामान्य रूप से बंद किया जाएगा।

Answer 3

नहीं। स्थानीय चर को व्यक्तिगत रूप से साफ करने की आवश्यकता नहीं है। जब ढेर पॉप हो जाता है, तो सभी स्थानीय चर इसके साथ ही चले जाएंगे।

Answer 4

नहीं। आप गतिशील रूप से आवंटित स्मृति को केवल रिसाव कर सकते हैं।

Answer 5

स्टैक वैरिएबल को फ़ंक्शन दर्ज करने के पल में परिभाषित (और आवंटित) परिभाषित किया जाता है, और जब आप फ़ंक्शन छोड़ते हैं तो पूरी तरह समाप्त हो जाते हैं (क्योंकि संपूर्ण कॉल स्टैक रिकॉर्ड पॉप हो जाता है)। फ़ंक्शन के अंदर चारों ओर उछालने की कोई भी मात्रा संभवतः पूरे समय आवंटित स्मृति के साथ किसी भी विनाश का कारण बन सकती है। कोड के माध्यम से आप जो निष्पादन पथ लेते हैं, भले ही नियंत्रण कॉलिंग फ़ंक्शन पर नियंत्रण लौटाए जाने पर स्टैक रिकॉर्ड पॉप हो जाएगा, और स्मृति मुक्त हो जाएगी।

Answer 6

गोटो हमेशा बुरा नहीं होता है, लेकिन आपके मामले में आपको शायद गोटो का उपयोग नहीं करना चाहिए।

गोटो here और here के अच्छे उपयोग के उदाहरण देखें।

यदि आपके पास एक लेबल है जो दायरे से बाहर है तो आपकी वस्तु को ढेर पर मुक्त कर दिया जाएगा।

उदाहरण:

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

यह प्रिंट होगा:

गुंजाइश
अंदर एक नाशक
एल लेबल के बाद

Answer 7

नहीं, आपके लूप में कोई भी स्वचालित चर प्रोग्रामिंग लीक का कारण नहीं बनता है यदि आप गोटो स्टेटमेंट के साथ अपने लूप से बाहर निकलते हैं।

Answer 8

अन्य उत्तरों सच हैं .... हालांकि, अगर आपको अलग-अलग लूप घोंसला करना है, तो मैं उन डिजाइनों पर सवाल उठाऊंगा जो उन्हें वहां रखे। उस तर्क को अलग-अलग कार्यों में विभाजित करना ऐसी समस्या को हल करने का एक बेहतर तरीका होगा।

Billy3

Answer 9

ढेर चर (ऑटो, नहीं autobots) नई के माध्यम से आवंटित चर की तरह "टपकाया" नहीं कर रहे हैं() या malloc()।

जहां तक ​​गेटोस की "बदसूरत" सिर्फ कुत्ते की तरह है। Knuth पढ़ें, वह Dijkstra के रूप में बस शानदार था। http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf पास्ता आधारित प्रोग्रामिंग से बचें, लेकिन सावधानीपूर्वक उपयोग स्पेगेटी में गिरावट नहीं आएगी।

डिजस्ट्रा उन्हें पसंद नहीं करते थे क्योंकि आप गेटोस के साथ जो कुछ भी कर सकते हैं, वह अन्य संरचित प्रोग्रामिंग तकनीकों के साथ किया जा सकता है और इसलिए अन्य संरचित कम त्रुटि प्रवण बनाने के लिए कम कोड का उपयोग करता है।

समझें कि गेटोस आपका पहला समाधान नहीं होना चाहिए, और उनका उपयोग करने के लिए अपने रास्ते से बाहर नहीं जाना चाहिए, लेकिन अगर यह समझ में आता है कि यह dogmatic lench mobs को सबमिट नहीं करता है। ब्रेक स्टेटमेंट उन मामलों के लिए डिज़ाइन किया गया है जो "गेटोस का उपयोग नहीं करेंगे" आदेश का सख्ती से पालन नहीं करते थे।

Answer 10

पिछड़ा गेटो रिसाव संसाधन होगा? या नीचे कोड के साथ कोई अन्य संभावित समस्याएं?

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 
     { 

     }