GOTO अभी भी हानिकारक माना जाता है? [बन्द है]

282

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

किन परिस्थितियों में गोटो के इस्तेमाल पर रोक लगाई गई है? कब बचना सबसे अच्छा है?

फॉलोअप सवाल के रूप में: C फंक्शंस, सेटजम्प और लॉन्गजम्प की एक जोड़ी प्रदान करता है, जो गोटो को न केवल वर्तमान स्टैक फ्रेम के भीतर, बल्कि किसी भी कॉलिंग फ्रेम के भीतर प्रदान करता है। क्या इनको गोटो जितना खतरनाक माना जाना चाहिए? अधिक खतरनाक?

दिज्कस्ट्रा ने खुद ही उस उपाधि पर अफसोस जताया, जिसके लिए वह जिम्मेदार नहीं था। EWD1308 के अंत में ( यहां भी .pdf) उन्होंने लिखा:

अंत में रिकॉर्ड के लिए एक छोटी कहानी। 1968 में, ACM के संचार ने " द गोटो स्टेटमेंट फॉर हानिकारक " शीर्षक के तहत मेरा एक टेक्स्ट प्रकाशित किया , जिसे बाद के वर्षों में सबसे अधिक बार संदर्भित किया जाएगा, अफसोस की बात है, हालांकि, अक्सर उन लेखकों द्वारा जिन्हें इसके अलावा इससे अधिक नहीं देखा गया था। शीर्षक, जो एक टेम्प्लेट बनकर मेरी प्रसिद्धि की आधारशिला बन गया: हम लगभग किसी भी एक्स के लिए "एक्स हानिकारक" माने जाने वाले शीर्षक के तहत सभी प्रकार के लेख देखेंगे, जिसमें एक शीर्षक "दिज्क्स्ट्रा हानिकारक माना जाता है"। लेकिन क्या हुआ था? मैंने शीर्षक के तहत एक पेपर प्रस्तुत किया था " गोटो बयान के खिलाफ एक मामला", जो, अपने प्रकाशन को गति देने के लिए, संपादक" संपादक को पत्र "में बदल गया था, और इस प्रक्रिया में उन्होंने इसे अपने स्वयं के आविष्कार का एक नया शीर्षक दिया था! संपादक निकल्ज़ विर्थ था।

इस विषय के बारे में एक अच्छी तरह से समझा जाने वाला क्लासिक पेपर, जो कि दिक्जस्त्र से मेल खाता है , को डोनाल्ड ई। नुथ द्वारा स्ट्रक्चर्ड प्रोग्रामिंग टू स्टेट्स टू गो , के साथ मैच किया गया है । दोनों को पढ़ना संदर्भ और विषय की गैर-हठवादी समझ को पुन: स्थापित करने में मदद करता है। इस पत्र में, इस मामले पर दीजकस्ट्रा की राय बताई गई है और यह और भी मजबूत है:

डोनाल्ड ई। नुथ: मेरा मानना ​​है कि इस तरह के दृश्य को प्रस्तुत करने से मैं वास्तव में दिज्कस्ट्रा के विचारों से असहमत नहीं हूं, क्योंकि उन्होंने हाल ही में निम्नलिखित लिखा है: "कृपया विश्वास करने के जाल में न पड़ें कि मैं इस बारे में बहुत अधिक हठधर्मी हूं" बयान पर जाएं]। मुझे इस बात का असहज अहसास है कि अन्य लोग धर्म से बाहर कर रहे हैं, जैसे कि प्रोग्रामिंग की वैचारिक समस्याओं को कोडिंग अनुशासन के एक सरल रूप से हल किया जा सकता है! "

language-agnostic  goto 
— MaD70
स्रोत
1
C # का गोटो वही नहीं है, जैसा गोटो दिज्कस्ट्रा के बारे में बात कर रहा था, ठीक यही कारण है कि दिज्क्स्ट्रा ने बात की थी। यही कारण है कि के रूप में इसे वापस तो था गोटो दोनों एक हानिकारक है, लेकिन यह भी एक बहुत कम आवश्यक है, क्योंकि आधुनिक भाषाओं वैकल्पिक नियंत्रण संरचनाओं प्रदान करते हैं। C # गोटो बेहद विवश है।
— १०:०१ पर १
25
जब वे स्पष्टता जोड़ते हैं तो गॉटोस अच्छे होते हैं। यदि आपके पास एक लंबा नेस्टेड लूप है, तो इसे "ब्रेक" चर सेट करने और तोड़ने से बेहतर है कि जब तक आप बाहर न निकल जाएं।
— सिमेंडोजो
28
यदि आपके पास 4 गहराई पर एक नेस्टेड लूप है (यह नहीं कि यह एक अच्छी बात है), तो सभी को तोड़कर अस्थायी मान स्थापित करने की आवश्यकता होती है। यहां एक गोटो मेरे लिए बहुत स्पष्ट है, और आईडीई को आसानी से दिखाना चाहिए कि गोटो कहां है। उस ने कहा, गोटो का उपयोग विरल होना चाहिए, और मेरी राय में केवल कोड छोड़ने के लिए नीचे जाएं
— simendsjo
7
मेरा सुझाव है कि आप नौ हजार और एक धागे को टैग करके पढ़ें goto।
— मत्ती विर्ककुनेन
5
उपयोग करने से स्पष्ट रूप से बदतर एक चीज है goto: एक को लागू करने के लिए एक साथ संरचित प्रोग्रामिंग टूल को हैक करना goto।

जवाबों:

184

निम्नलिखित कथन सामान्यीकरण हैं; हालांकि, अपवाद को हल करना हमेशा संभव है, यह आमतौर पर (मेरे अनुभव और विनम्र राय में) जोखिमों के लायक नहीं है।

  1. मेमोरी पतों (या तो जीओटीओ या कच्चे पॉइंटर्स) का बिना उपयोग के आसानी से परिहार्य गलतियों को उपलब्ध कराने के कई अवसर प्रदान करता है।
  2. कोड में किसी विशेष "स्थान" पर पहुंचने के जितने अधिक तरीके हैं, उतना ही कम आत्मविश्वास इस बात पर हो सकता है कि उस बिंदु पर सिस्टम की स्थिति क्या है। (निचे देखो।)
  3. संरचित प्रोग्रामिंग IMHO "GOTO से बचना" के बारे में कम है और कोड की संरचना बनाने के बारे में अधिक डेटा की संरचना से मेल खाता है। उदाहरण के लिए, एक दोहराई जाने वाली डेटा संरचना (जैसे सरणी, अनुक्रमिक फ़ाइल, आदि) स्वाभाविक रूप से कोड की एक दोहराया इकाई द्वारा संसाधित होती है। बिल्ट-इन स्ट्रक्चर्स होने (जैसे, जबकि, जब तक, प्रत्येक के लिए, आदि) प्रोग्रामर को उसी क्लिच्ड कोड पैटर्न को दोहराने के टेडियम से बचने की अनुमति देता है।
  4. भले ही GOTO निम्न-स्तरीय कार्यान्वयन विवरण हो (हमेशा मामला नहीं!) यह उस स्तर से नीचे है जो प्रोग्रामर को सोचना चाहिए। कच्चे बाइनरी में कितने प्रोग्रामर अपनी व्यक्तिगत चेकबुक को संतुलित करते हैं? कितने प्रोग्रामर इस बात की चिंता करते हैं कि डिस्क पर किस सेक्टर में एक विशेष रिकॉर्ड है, बजाय एक डेटाबेस इंजन को एक कुंजी प्रदान करने के (और भौतिक डिस्क क्षेत्रों के संदर्भ में हमारे सभी कार्यक्रमों को वास्तव में लिखे जाने पर कितने तरीके गलत हो सकते हैं)?

फुटनोट्स ऊपर:

बिंदु 2 के बारे में, निम्नलिखित कोड पर विचार करें:

a = b + 1
/* do something with a */

कोड में "कुछ करें" बिंदु पर, हम उच्च आत्मविश्वास के साथ राज्य कर सकते हैं जो aइससे अधिक है b। (हां, मैं अनकैप्ड पूर्णांक ओवरफ्लो की संभावना को नजरअंदाज कर रहा हूं। आइए एक सरल उदाहरण को ध्यान में न रखें।)

दूसरी ओर, यदि कोड इस तरह से पढ़ा था:

...
goto 10
...
a = b + 1
10: /* do something with a */
...
goto 10
...

10 लेबल करने के तरीकों की बहुलता का मतलब है कि हमें उस बिंदु पर aऔर उसके बीच संबंधों के बारे में आश्वस्त होने के लिए बहुत अधिक मेहनत करनी होगी b। (वास्तव में, सामान्य मामले में यह अनिर्दिष्ट है!)

बिंदु 4 के बारे में, कोड में "कहीं जाने" की पूरी धारणा सिर्फ एक रूपक है। CPU और इलेक्ट्रॉनों (बेकार गर्मी के लिए) को छोड़कर सीपीयू के अंदर कहीं भी कुछ भी वास्तव में "नहीं" हो रहा है। कभी-कभी हम दूसरे, अधिक उपयोगी, एक के लिए एक रूपक छोड़ देते हैं। मुझे याद आता है कि (कुछ दशक पहले!) एक भाषा जहाँ

if (some condition) {
  action-1
} else {
  action-2
}

एक वर्चुअल मशीन पर एक्शन -1 और एक्शन -2 को आउट-ऑफ-लाइन पैरामीटर रहित दिनचर्या के रूप में लागू करके लागू किया गया था, फिर एक एकल-तर्क वीएम ओपोड का उपयोग करके जो एक या दूसरे को लागू करने के लिए शर्त के बूलियन मूल्य का उपयोग करता था। अवधारणा बस "यहाँ क्या जाना है" के बजाय "चुनें या यहाँ जाएँ" चुनें। फिर, बस रूपक का एक परिवर्तन।

— joel.neely
स्रोत
2
एक अच्छा बिंदु। उच्च-स्तरीय भाषाओं में गोटो का वास्तव में कोई मतलब नहीं है (जावा में तरीकों के बीच कूदने पर विचार करें)। एक हास्केल फ़ंक्शन में एकल अभिव्यक्ति हो सकती है; एक गोटो के साथ बाहर कूद की कोशिश करो!
— यांत्रिक घोंघा
2
पोस्टस्क्रिप्ट आपके बिंदु 4 उदाहरण की तरह काम करता है।
— लूज़र
स्मॉलटाक बिंदु 4 उदाहरण के समान ही काम करता है, अगर "इसी तरह" से आपका मतलब है "प्रक्रियात्मक भाषाओं जैसा कुछ भी नहीं"। : पी भाषा में कोई प्रवाह नियंत्रण नहीं है; सभी निर्णय बहुरूपता के माध्यम से नियंत्रित किए जाते हैं ( trueऔर falseविभिन्न प्रकार के होते हैं), और यदि / तो प्रत्येक शाखा मूल रूप से एक लंबोदर है।
— cHao
ये मान्य बिंदु हैं, लेकिन अंत में वे केवल यह दोहराते हैं कि गोटो कितना बुरा हो सकता है "अगर दुरुपयोग"। तोड़ना, जारी रखना, बाहर निकलना, लौटना, गॉसब, सेटलआउट, ग्लोबल, शामिल करना, आदि सभी आधुनिक तकनीकें हैं जो मानसिक रूप से चीजों के प्रवाह को ट्रेस करने की आवश्यकता होती हैं और सभी को स्पेगेटी कोड बनाने के लिए दुरुपयोग किया जा सकता है और चर राज्यों की अनिश्चितता पैदा करने के लिए चारों ओर छोड़ दें। निष्पक्ष होने के लिए, हालांकि मैंने पहले गोटो के खराब उपयोग को कभी नहीं देखा है, मैंने भी केवल एक या दो बार इसका इस्तेमाल किया है। यह कथन बोलता है कि उपयोग करने के लिए हमेशा बेहतर चीजें होती हैं।
— बीजर
gotoएक आधुनिक प्रोग्रामिंग भाषा (गो) में stackoverflow.com/a/11065563/3309046 ।
— निशांथ्स
245

XKCD का गोटो कॉमिक

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

मुझे लगा कि यह कॉमिक इस बात को दर्शाती है कि खूबसूरती से "मैं कार्यक्रम के प्रवाह का पुनर्गठन कर सकता था, या इसके बजाय एक छोटे से 'गोटो' का उपयोग कर सकता था।" एक GOTO एक कमजोर तरीका है जब आपके पास कमजोर डिजाइन है। वेलोसिरैप्टर कमजोरों का शिकार करते हैं ।

— जिम मैककेथ
स्रोत
41
जीओटीओ 'जंपिंग' को एक मनमाने स्थान से दूसरे मनमाने स्थान पर कर सकता है। वेलोसिरैप्टर यहां से कहीं कूद गया!
— १२
29
मैं मजाक को बिल्कुल भी हास्यास्पद नहीं मानता क्योंकि हर कोई जानता है कि आपको निष्पादित करने से पहले लिंक करना होगा।
— किंजल दीक्षित
31
आपका सहकर्मी गलत है, और जाहिर है कि नथ का पेपर नहीं पढ़ा था।
— जिम बेल्टर
27
मैंने किसी गोटे से बचने के लिए वर्षों से लगाए गए किसी भी तरह के ओब्सेस्ड और अन्यथा कंट्रोल्ड कोड को नहीं देखा है। @jimmcKeeth, ऊपर xkcd कार्टून स्थापित नहीं करता है कि गोटो कमजोर है। यह हिस्टीरिया का उपयोग करने के आसपास इसका मजाक उड़ा रहा है।
4
आपको पता चलता है कि डेल्फी लाइब्रेरी सोर्स कोड में गोटो स्टेटमेंट्स हैं। और ये गोटो के उपयुक्त उपयोग हैं।
— डेविड हेफर्नन
131

कभी-कभी एकल फ़ंक्शन में अपवाद हैंडलिंग के विकल्प के रूप में GOTO का उपयोग करना मान्य है:

if (f() == false) goto err_cleanup;
if (g() == false) goto err_cleanup;
if (h() == false) goto err_cleanup;

return;

err_cleanup:
...

COM कोड इस पैटर्न में काफी बार गिरता है।

— रोब वॉकर
स्रोत
29
मैं मानता हूं, ऐसे वैध उपयोग के मामले हैं, जहां गोटो कोड को सरल बना सकते हैं और इसे अधिक पठनीय / बनाए रखने योग्य बना सकते हैं, लेकिन लगता है कि गोटो-फोबिया किसी तरह का हो सकता है ...
— पॉप कैटालिन
48
@ याकूब: अगर यह स्थानीय चरों को साफ कर रहा है तो इरॉटेक कोड को एक सबरूटीन में स्थानांतरित करना मुश्किल है।
— निकी
4
दरअसल, मैंने इसे COM / VB6 में सिर्फ इसलिए इस्तेमाल किया क्योंकि मेरे पास कोई विकल्प नहीं था , इसलिए नहीं कि यह एक विकल्प था। मैं आजकल कितनी खुश हूं कि कोशिश / कैच / आखिर में।
— रुई क्रेविरो
10
@ user4891 मुहावरेदार सी ++ तरीका {} कैच () {क्लीनअप; }, बल्कि आरएआईआई, जहां संसाधनों को साफ करने की आवश्यकता होती है, ऐसा विध्वंसक क्षेत्रों में किया जाता है। हर निर्माणकर्ता / विध्वंसक ठीक एक संसाधन का प्रबंधन करता है।
— डेविड स्टोन
5
ग के बिना सी में इसे लिखने के दो तरीके हैं; और दोनों बहुत छोटे हैं। या तो: if (f ()) if (g ()) if (h ()) सफलता लौटाता है; साफ - सफाई(); वापसी की विफलता; या: यदि (f () && g () और& h ()) सफलता लौटाता है; साफ - सफाई(); वापसी की विफलता;
— LHP
124

मैं केवल एक बार एक गोटो का उपयोग करके याद कर सकता हूं। मेरे पास पांच नेस्टेड गिने हुए छोरों की एक श्रृंखला थी और मुझे कुछ शर्तों के आधार पर अंदर से पूरी संरचना को तोड़ने में सक्षम होना चाहिए:

for{
  for{
    for{
      for{
        for{
          if(stuff){
            GOTO ENDOFLOOPS;
          }
        }
      }
    }
  }
}

ENDOFLOOPS:

मैं बस आसानी से बूलियन ब्रेक चर घोषित कर सकता था और इसे प्रत्येक लूप के लिए सशर्त के हिस्से के रूप में इस्तेमाल किया था, लेकिन इस उदाहरण में मैंने फैसला किया कि एक गोटो व्यावहारिक और बस पठनीय के रूप में था।

किसी भी वेलोसर्प्टर्स ने मुझ पर हमला नहीं किया।

— शस्टिमर
स्रोत
83
"इसे एक फंक्शन में रिफ्लेक्टर करें और गोटो को रिटर्न के साथ बदलें :)", और अंतर है? वास्तव में क्या अंतर है? वापस भी नहीं जाना है? रिटर्न भी गोटो की तरह संरचित प्रवाह को ब्रेक करता है, और इस मामले में वे इसे उसी तरह से करते हैं (भले ही गोटो का मतलब चीजों के लिए इस्तेमाल किया जा सकता है)
— पॉप कैटालिन
38
बहुत सारे छोरों को घोंसला बनाना आमतौर पर एक कोड गंध है जो सभी स्वयं है। जब तक आप कर रहे हैं, जैसे, 5-आयामी सरणी गुणा, ऐसी स्थिति को चित्रित करना मुश्किल है जहां कुछ आंतरिक छोरों को छोटे कार्यों में उपयोगी रूप से नहीं निकाला जा सकता है। अंगूठे के सभी नियमों की तरह, मुझे लगता है कि कुछ अपवाद हैं।
— डग मैकलीन
5
इसे रिटर्न के साथ बदलने पर ही काम होता है जब आप रिटर्न का समर्थन करने वाली भाषा का उपयोग कर रहे हों।
— लोरेन Pechtel
31
@ एलप्पी: जिस पीढ़ी ने विद्रोह किया gotoऔर हमें संरचित प्रोग्रामिंग दी, उसने भी इसी कारण शुरुआती रिटर्न को अस्वीकार कर दिया। यह नीचे आता है कि कोड कितना पठनीय है, यह स्पष्ट रूप से प्रोग्रामर के इरादे को व्यक्त करता है। खराब सामंजस्य में दुर्भावनापूर्ण कीवर्ड परिणामों का उपयोग करने से बचने के लिए किसी अन्य उद्देश्य के लिए एक समारोह बनाना: बीमारी से इलाज बदतर है।
— मुद
21
@ButtleButkus: सच कहूं, तो यह उतना ही बुरा है, अगर बुरा नहीं है। कम से कम एक के साथ goto, एक लक्ष्य को स्पष्ट रूप से निर्दिष्ट कर सकता है। साथ break 5;, (1) मैं गंतव्य खोजने के लिए पाश बंद होने गिनती करने के लिए है, और (2) यदि लूप संरचना कभी बदलती है, तो गंतव्य को सही रखने के लिए अच्छी तरह से उस संख्या को बदलने की आवश्यकता हो सकती है। अगर मैं बचने जा रहा हूं goto, तो लाभ इस तरह से मैन्युअल रूप से ट्रैक करने में नहीं होना चाहिए।
— cHao
93

हमारी पहले से ही यह चर्चा थी और मैं अपनी बात पर खड़ा हूं ।

इसके अलावा, मैं "के रूप में उच्च स्तर की भाषा संरचनाओं का वर्णन लोगों के साथ तंग आ गया हूँ gotoभेष में" क्योंकि वे स्पष्ट रूप से बात नहीं मिला है सब पर । उदाहरण के लिए:

यहां तक ​​कि योजना में उन्नत निरंतरता नियंत्रण संरचना को एक परिष्कृत गोटो के रूप में वर्णित किया जा सकता है।

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

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

— कोनराड रूडोल्फ को दर्शाता है
स्रोत
82
बेशक, एक चट्टान का उचित उपयोग एक हथौड़ा के रूप में नहीं है। इसके उचित उपयोगों में से एक एक पीस पत्थर है, या अन्य उपकरणों को तेज करने के लिए। यहां तक ​​कि नीच चट्टान, जब ठीक से उपयोग किया जाता है तो एक अच्छा उपकरण है। आपको बस उचित उपयोग खोजना होगा। वही गोटो के लिए चला जाता है।
— कबि नोव
10
तो गोटो का उचित उपयोग क्या है? कल्पना करने योग्य हर मामले के लिए एक और उपकरण बेहतर अनुकूल है। और यहां तक कि अपने पीस पत्थर वास्तव में, उच्च तकनीक उपकरण आजकल द्वारा बदल दिया है, भले ही वे अभी भी बना रहे हैं की चट्टान। एक कच्चे माल और एक उपकरण के बीच एक बड़ा अंतर है।
— कोनराड रूडोल्फ
8
@jalf: गोटो सबसे निश्चित रूप से करता है सी # में मौजूद हैं। देखें stackoverflow.com/questions/359436/...
— जॉन स्कीट
51
मैं बहुत से लोगों को इस पद के लिए मंजूरी देता हूं। आपकी पोस्ट केवल इसलिए प्रभावी लगी क्योंकि आपने कभी यह सवाल करने की जहमत नहीं उठाई कि आप वास्तव में क्या तर्क दे रहे थे, इस प्रकार आप अपनी गिरावट को नोटिस करने में विफल रहे। मुझे आपकी पूरी पोस्ट को देखने के लिए अनुमति दें: "हर स्थिति में एक गोटो के लिए एक बेहतर उपकरण है, इसलिए गोटो का उपयोग कभी नहीं किया जाना चाहिए।" यह एक तार्किक द्विसंयोजक है, और जैसे कि आपकी पूरी पोस्ट अनिवार्य रूप से इस सवाल का जवाब दे रही है "आप कैसे जानते हैं कि हर स्थिति में एक गोटो के लिए एक बेहतर उपकरण है?"
— स्टाइल
10
@ कोडिंग: नहीं, आप पोस्ट करने के लिए पूरी तरह से चूक गए। यह एक अलग, पूर्ण तर्क के बजाय एक रिपॉस्ट था । मैंने केवल मुख्य तर्क "फॉर" में गिरावट को इंगित किया goto। आप अभी तक सही हैं क्योंकि मैं gotoप्रति सेगमेंट के खिलाफ एक तर्क नहीं देता हूं - मेरा इरादा नहीं था - इसलिए कोई सवाल नहीं है।
— कोनराड रुडोल्फ
91

गोटो सिर्फ एक कार्यक्रम में शामिल करने के लिए मेरी चीजों की सूची पर बहुत कम है। इसका मतलब यह नहीं है कि यह अस्वीकार्य है।

गोटो राज्य मशीनों के लिए अच्छा हो सकता है। लूप में एक स्विच स्टेटमेंट है (विशिष्ट महत्व के क्रम में): (ए) वास्तव में नियंत्रण प्रवाह का प्रतिनिधि नहीं है, (बी) बदसूरत, (सी) भाषा और संकलक के आधार पर संभावित अक्षम है। इसलिए आप प्रति राज्य एक फ़ंक्शन लिखना, और "NEXT_STATE लौटना" जैसे काम कर रहे हैं; जो गोटो की तरह भी दिखता है।

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

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

अपवाद या अपवाद जैसे व्यवहार को लागू करने के लिए setjmp / longjmp अच्छा हो सकता है। जबकि सार्वभौमिक रूप से प्रशंसा नहीं की गई है, अपवादों को आमतौर पर "वैध" नियंत्रण संरचना माना जाता है।

setjmp / longjmp इस अर्थ में गोटो से 'अधिक खतरनाक' है कि वे सही ढंग से उपयोग करने के लिए कठिन हैं, कभी भी समझ में नहीं आता।

वहाँ कभी नहीं गया है, और न ही कभी होगा, किसी भी भाषा जिसमें खराब कोड लिखना सबसे कम मुश्किल है। - डोनाल्ड नथ।

सी से गोटो को लेना सी में अच्छा कोड लिखना आसान नहीं होगा। वास्तव में, यह इस बिंदु को याद नहीं करेगा कि सी को एक गौरवशाली कोडांतरक भाषा के रूप में अभिनय करने में सक्षम माना जाता है।

इसके बाद यह "पॉइंटर्स को हानिकारक माना जाता है", फिर "डक टाइपिंग को हानिकारक माना जाता है"। जब वे आपके असुरक्षित प्रोग्रामिंग निर्माण को दूर करने के लिए आते हैं, तो आपका बचाव करने के लिए कौन बचा होगा? एह?

— स्टीव जेसप को रिवील किया
स्रोत
14
Personaly, यह वह टिप्पणी है जिसे मैंने चेक दिया होगा। एक बात जो मैं पाठकों को बताना चाहूंगा वह यह है कि गूढ़ शब्द "स्टेट मशीन" में लेक्सिकल एनालाइजर जैसी रोजमर्रा की चीजें शामिल हैं। किसी दिन lex का आउटपुट देखें। गोटो से भरा हुआ।
— TED
2
आप एक लूप (या इवेंट हैंडलर) के अंदर एक स्विच स्टेटमेंट का उपयोग कर सकते हैं ताकि राज्य मशीनों को ठीक किया जा सके। मैंने बहुत सारी राज्य मशीनें बिना जम्प या गोटो का उपयोग किए बिना की हैं।
— स्कॉट व्हिटलॉक
11
+1 राज्य मशीनों पर वे तीर किसी भी अन्य नियंत्रण संरचना की तुलना में 'गोटो' के अधिक निकट होते हैं। ज़रूर, आप लूप के अंदर एक स्विच का उपयोग कर सकते हैं - जैसे आप अन्य समस्याओं के लिए थोड़ी देर के बजाय गोटो का एक गुच्छा उपयोग कर सकते हैं, लेकिन यह आमतौर पर एक विचार है; जो इस चर्चा का पूरा बिंदु है।
— एडमंड
2
क्या मैं आपको उस अंतिम पैराग्राफ पर उद्धृत कर सकता हूं?
— क्रिस लुट्ज़
2
और, यहाँ 2013 में, हम पहले ही हिट कर चुके हैं (और थोड़े अतीत में चले गए) "संकेतकर्ता हानिकारक माना जाता है" चरण।
— इस्सा मीडोज़
68

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

कुछ मार्ग:

लिनुस: "नहीं, आपको सीएस लोगों द्वारा दिमाग लगाया गया है जिन्होंने सोचा था कि निकलौस विर्थ वास्तव में जानता था कि वह किस बारे में बात कर रहा था। उसने नहीं किया। उसके पास कोई भयावह सुराग नहीं है।"

-

लिनुस: "मुझे लगता है कि गोटो ठीक हैं, और वे अक्सर बड़ी मात्रा में इंडेंटेशन की तुलना में अधिक पठनीय होते हैं।"

-

लिनुस: "बेशक, पास्कल जैसी बेवकूफ भाषाओं में, जहां लेबल वर्णनात्मक नहीं हो सकते हैं, गोटो का बुरा हो सकता है।"

— Marcio Aguiar
स्रोत
9
यह एक अच्छी बात है कि कैसे? वे इसके उपयोग की चर्चा उस भाषा में कर रहे हैं जिसमें और कुछ नहीं है। जब आप विधानसभा में हैं प्रोग्रामिंग, सभी शाखाओं और छलांग हैं गोटो के। और सी है, और, एक "पोर्टेबल विधानसभा भाषा" थी। इसके अलावा, आप जो उद्धरण देते हैं, वह इस बारे में कुछ नहीं कहता है कि वह क्यों सोचता है कि गोटो अच्छा है।
— :
5
वाह। जो पढ़ने में निराशाजनक है। आपको लगता है कि लाइनस टॉर्वाल्ड्स जैसा एक बड़ा ओएस पुरुष यह कहने से बेहतर जानता होगा। पास्कल (पुराने-स्कूल पास्कल, आधुनिक वस्तु संस्करण नहीं) जो मैक ओएस क्लासिक 68k अवधि के दौरान लिखा गया था, और यह अपने समय का सबसे उन्नत ऑपरेटिंग सिस्टम था।
— मेसन व्हीलर
6
@mason Classic Mac OS में कुछ पास्कल लाइब्रेरियाँ थीं (अंततः - पास्कल रनटाइम ने शुरुआती मैक में बहुत अधिक मेमोरी ले ली थी) लेकिन कोर कोड का अधिकांश भाग असेंबलर में लिखा गया था, खासकर ग्राफिक्स और यूआई रूटीन।
— जिम डोवी
30
लाइनस केवल बाहर निकलने की स्थिति को संभालने के लिए गोटो (उस चर्चा में रिक वैन रिएल की तरह) बहस करता है, और वह जटिलता के आधार पर ऐसा करता है कि सी के वैकल्पिक निर्माणों को लाएगा यदि वे इसके बजाय उपयोग किए गए थे।
— चार्ल्स स्टीवर्ट
21
इस मुद्दे पर IMHO लाइनस सही है। उनका कहना है कि कर्नेल कोड, सी में लिखा गया है, जिसे अपवाद से निपटने के समान लागू करने की आवश्यकता है, यह सबसे स्पष्ट रूप से और बस एक गोटो का उपयोग करके लिखा गया है। मुहावरा goto cleanup_and_exitगोटो के कुछ "अच्छा" का उपयोग करता है में से एक अब छोड़ दिया है कि हम है for, whileऔर ifहमारे नियंत्रण प्रवाह का प्रबंधन करने के। इसे भी देखें: programmers.stackexchange.com/a/154980
— स्टीवेहा
50

सी में, gotoकेवल वर्तमान फ़ंक्शन के दायरे में काम करता है, जो किसी भी संभावित बग को स्थानीय बनाने के लिए जाता है। setjmpऔर longjmpकहीं अधिक खतरनाक हैं, गैर-स्थानीय, जटिल और कार्यान्वयन-निर्भर होना। हालांकि, व्यवहार में, वे कई समस्याओं का कारण अस्पष्ट और असामान्य हैं।

मेरा मानना ​​है कि gotoसी में खतरा बहुत अतिरंजित है। याद रखें कि मूल gotoतर्क पुराने ज़माने की BASIC जैसी भाषाओं के दिनों में हुए, जहाँ शुरुआती लोग स्पेगेटी कोड को इस तरह लिखते थे:

3420 IF A > 2 THEN GOTO 1430

यहाँ लाइनस एक उपयुक्त उपयोग का वर्णन करता है goto: http://www.kernel.org/doc/Documentation/CodingStyle (अध्याय 7)।

— smh
स्रोत
7
जब BASIC पहली बार उपलब्ध हुआ था, तो GOTO nnnn और GOSUB mmmm के आसपास कूदने के तरीकों के रूप में कोई विकल्प नहीं था। बाद में संरचित निर्माणों को जोड़ा गया।
— जोनाथन लेफ़लर
7
आप इस बिंदु को याद कर रहे हैं ... तब भी आपको स्पेगेटी लिखना नहीं आता था ... आपके GOTO हमेशा एक अनुशासित तरीके से उपयोग किए जा सकते हैं
— जोएलफैन
यह भी ध्यान देने योग्य है कि setjmp/ longjmpका व्यवहार केवल तब निर्दिष्ट किया गया था जब उन्हें उसी स्थान के भीतर अन्य स्थानों से एक दायरे में कूदने के साधन के रूप में उपयोग किया गया था। एक बार नियंत्रण के दायरे को छोड़ दिया जाता है जहां setjmpनिष्पादित किया जाता है, इसके longjmpद्वारा बनाई गई संरचना पर उपयोग करने का कोई भी प्रयास setjmpअपरिभाषित व्यवहार का परिणाम देगा।
— सुपरकाट
9
BASIC के कुछ संस्करण आपको करने देंगे GOTO A * 40 + B * 200 + 30। यह देखना मुश्किल नहीं है कि यह बहुत आसान कैसे था, और बहुत खतरनाक है।
— जॉन हैना
1
@ हेजल यह अभिव्यक्ति की गणना करेगा और फिर उस नंबर के साथ कोड की लाइन पर जाएगा (स्पष्ट लाइन नंबर सबसे पहले की बोलियों की आवश्यकता थी)। ZX स्पेक्ट्रम बेसिक वह था जो स्वीकार करेगा कि
— जॉन हैना
48

आज, GOTOबयान के बारे में बड़ी बात देखना मुश्किल है क्योंकि "संरचित प्रोग्रामिंग" लोगों ने ज्यादातर बहस जीत ली और आज की भाषाओं में बचने के लिए पर्याप्त नियंत्रण प्रवाह संरचनाएं हैं GOTO।

gotoएक आधुनिक सी कार्यक्रम में एस की संख्या की गणना करें । अब की संख्या जोड़ने break, continueऔर returnबयान। इसके अलावा, कई बार आप का उपयोग की संख्या जोड़ने if, else, while, switchया case। इस बारे में कि GOTOआपका कार्यक्रम 1968 में जब आप FORTRAN या BASIC में लिख रहे थे, तब कितने समय के लिए होगा जब Dijkstra ने अपना पत्र लिखा था।

उस समय प्रोग्रामिंग भाषाओं में नियंत्रण प्रवाह की कमी थी। उदाहरण के लिए, मूल डार्टमाउथ बुनियादी में:

  • IFबयानों में कोई दम नहीं था ELSE। यदि आप एक चाहते थे, तो आपको लिखना था:

    100 IF NOT condition THEN GOTO 200
...stuff to do if condition is true...
190 GOTO 300
200 REM else
...stuff to do if condition is false...
300 REM end if

  • यहां तक ​​कि अगर आपके IFबयान की ज़रूरत नहीं थी ELSE, तब भी यह एक ही लाइन तक सीमित था, जिसमें आमतौर पर एक होता था GOTO।

  • कोई DO...LOOPबयान नहीं था । गैर- FORछोरों के लिए, आपको एक स्पष्ट GOTOया IF...GOTOशुरुआत के साथ लूप को समाप्त करना होगा।

  • नहीं था SELECT CASE। आपको इस्तेमाल करना था ON...GOTO।

तो, आप अपने कार्यक्रम में बहुत से के साथ समाप्त हुए GOTO। और आप GOTOकिसी एक सबरूटीन के भीतर एस के प्रतिबंध पर निर्भर नहीं हो सकते (क्योंकि सबरूटीन GOSUB...RETURNकी इतनी कमजोर अवधारणा थी), इसलिए ये कहीं भीGOTO जा सकते हैं । जाहिर है, यह नियंत्रण प्रवाह का पालन करने के लिए कठिन बना दिया।

यहीं से GOTOआंदोलन विरोधी आंदोलन चला।

— dan04
स्रोत
एक और बात ध्यान देने की है कि कोड लिखने का पसंदीदा तरीका यदि किसी में एक लूप में कुछ कोड होता है जिसे शायद ही कभी निष्पादित करना होगा 420 if (rare_condition) then 3000// 430 and onward: rest of loop and other main-line code// 3000 [code for rare condition]// 3230 goto 430। उस तरह का कोड लिखना जो किसी भी ली गई शाखाओं या सामान्य मुख्य-लाइन के मामले में कूदने से बचता है, लेकिन यह चीजों का पालन करना कठिन बनाता है। असेंबली कोड में शाखा परिहार बदतर हो सकता है, अगर कुछ शाखाएं जैसे +/- 128 बाइट्स तक सीमित हैं और कभी-कभी पूरक जोड़े नहीं हैं (जैसे "cjne" मौजूद है, लेकिन "सीजे" नहीं)।
— सुपरकैट
मैंने एक बार 8x51 के लिए कुछ कोड लिखा था जिसमें एक रुकावट थी जो हर 128 चक्र में एक बार चलती थी। ISR के सामान्य मामले में बिताए गए प्रत्येक अतिरिक्त चक्र में मेनलाइन कोड की निष्पादन गति 1% से अधिक कम हो जाएगी (मुझे लगता है कि 128 में से लगभग 90 चक्र आमतौर पर मेन-लाइन के लिए उपलब्ध थे), और कोई भी शाखा निर्देश दो चक्र लेगा ( दोनों शाखाओं में बंटने और गिरने के मामलों के माध्यम से)। कोड में दो तुलनाएं थीं - एक जो आमतौर पर बराबर रिपोर्ट करेगी; अन्य, नहीं के बराबर। दोनों मामलों में, दुर्लभ-केस कोड 128 बाइट्स से अधिक दूर था। तो ...
— सुपरकैट
cjne r0,expected_value,first_comp_springboard/..// cjne r1,unexpected_value,second_comp_fallthrough// `ajmp second_comp_target` first_comp_springboard: ajmp first_comp_target// second_comp_fallthrough: ...। बहुत अच्छा कोडिंग पैटर्न नहीं है, लेकिन जब व्यक्तिगत चक्रों की गणना होती है, तो व्यक्ति ऐसी चीजों को करता है। बेशक, 1960 के दशक में अनुकूलन के ऐसे स्तर आज की तुलना में अधिक महत्वपूर्ण थे, खासकर जब से आधुनिक सीपीयू को अक्सर अजीब अनुकूलन की आवश्यकता होती है, और बस-इन-टाइम संकलन सिस्टम सीपीयू के लिए अनुकूलन कोड लागू करने में सक्षम हो सकते हैं जो तब मौजूद नहीं थे। प्रश्न में कोड लिखा गया था।
— सुपरकैट
34

कुछ मामलों में "वास्तविक" अपवाद हैंडलिंग के लिए गो एक प्रकार का स्टैंड-इन प्रदान कर सकता है। विचार करें:

ptr = malloc(size);
if (!ptr) goto label_fail;
bytes_in = read(f_in,ptr,size);
if (bytes_in=<0) goto label_fail;
bytes_out = write(f_out,ptr,bytes_in);
if (bytes_out != bytes_in) goto label_fail;

जाहिर है कि इस कोड को कम जगह लेने के लिए सरलीकृत किया गया था, इसलिए विवरणों पर भी मत लटकाओ। लेकिन एक विकल्प पर विचार करें कि मैंने कोडो द्वारा उत्पादन कोड में सभी कई बार देखा है जो गोटो का उपयोग करने से बचने के लिए बेतुकी लंबाई में जा रहा है:

success=false;
do {
    ptr = malloc(size);
    if (!ptr) break;
    bytes_in = read(f_in,ptr,size);
    if (count=<0) break;
    bytes_out = write(f_out,ptr,bytes_in);
    if (bytes_out != bytes_in) break;
    success = true;
} while (false);

अब कार्यात्मक रूप से यह कोड ठीक यही काम करता है। वास्तव में, संकलक द्वारा उत्पन्न कोड लगभग समान है। हालांकि, नोगोटो (अकादमिक फटकार के खूंखार भगवान) को खुश करने के लिए प्रोग्रामर के उत्साह में , इस प्रोग्रामर ने अंतर्निहित मुहावरे को पूरी तरह से तोड़ दिया है जो whileलूप का प्रतिनिधित्व करता है, और कोड की पठनीयता पर एक वास्तविक संख्या किया। यह बेहतर नहीं है।

तो, कहानी का नैतिक है, अगर आप अपने आप को गोटो का उपयोग करने से बचने के लिए वास्तव में कुछ बेवकूफ का सहारा ले रहे हैं, तो नहीं।

— tylerl
स्रोत
1
हालाँकि मैं यहाँ आप जो कह रहा हूँ, उससे सहमत हूँ, यह तथ्य कि breakकथन एक नियंत्रण संरचना के अंदर हैं , वास्तव में यह स्पष्ट करता है कि वे क्या करते हैं। gotoउदाहरण के साथ , कोड को पढ़ने वाले व्यक्ति को लेबल खोजने के लिए कोड को देखना होगा, जो सिद्धांत रूप में, वास्तव में नियंत्रण संरचना से पहले हो सकता है। मुझे निर्णय लेने के लिए पुरानी शैली के सी के साथ पर्याप्त अनुभव नहीं है कि एक निश्चित रूप से दूसरे से बेहतर है, लेकिन किसी भी तरह से व्यापार-बंद हैं।
— विवियन नदी
5
@ डैनियल एलेन लैंडन: तथ्य यह है कि breakएस एक लूप के अंदर हैं यह बिल्कुल स्पष्ट करता है कि वे लूप से बाहर निकलते हैं । "वास्तव में वे क्या करते हैं" ऐसा नहीं है, वास्तविकता में, वहाँ एक लूप नहीं है! इसमें कुछ भी कभी भी दोहराने का मौका नहीं है, लेकिन यह अंत तक स्पष्ट नहीं है। तथ्य यह है कि आपके पास एक "लूप" है जो कभी भी एक से अधिक बार नहीं चलता है, इसका मतलब है कि नियंत्रण संरचनाओं का दुरुपयोग किया जा रहा है। gotoउदाहरण के साथ , प्रोग्रामर कह सकता है goto error_handler;। यह अधिक स्पष्ट है, और पालन करना भी कम कठिन है। (Ctrl + F, "error_handler:" लक्ष्य खोजने के लिए। "}" के साथ ऐसा करने का प्रयास करें।)
— cHao
1
मैंने एक बार एक एयर ट्रैफिक कंट्रोल सिस्टम में आपके दूसरे उदाहरण के समान कोड देखा था - क्योंकि 'गोटो हमारे लेक्सिकॉन में नहीं है'।
— QED
30

डोनाल्ड ई। नुथ ने 1992 के "लिटरेट प्रोग्रामिंग" नामक पुस्तक में इस सवाल का जवाब दिया। पी पर। 17 एक निबंध है " गोटो स्टेटमेंट्स के साथ संरचित प्रोग्रामिंग " (पीडीएफ)। मुझे लगता है कि लेख को अन्य पुस्तकों में भी प्रकाशित किया गया होगा।

लेख में दिक्जस्ट्रा के सुझाव का वर्णन किया गया है और उन परिस्थितियों का वर्णन किया गया है जहाँ यह मान्य है। लेकिन वह कई काउंटर उदाहरण (समस्याएं और एल्गोरिदम) भी देता है जिन्हें केवल संरचित लूप का उपयोग करके आसानी से पुन: प्रस्तुत नहीं किया जा सकता है।

लेख में समस्या, इतिहास, उदाहरण और काउंटर उदाहरणों का पूरा विवरण है।

— ब्रूनो रैन्शर्ट
स्रोत
25

गोटो को मददगार माना।

मैंने 1975 में प्रोग्रामिंग शुरू की। 1970 के दशक के युग के प्रोग्रामरों के लिए, "गोटो को हानिकारक माना जाता है" शब्द कम या ज्यादा कहा गया कि आधुनिक नियंत्रण संरचनाओं के साथ नई प्रोग्रामिंग भाषाएं कोशिश करने लायक थीं। हमने नई भाषाओं की कोशिश की। हम जल्दी से रूपांतरित हुए। हम कभी वापस नहीं गए।

हम कभी पीछे नहीं हटे, लेकिन, अगर आप छोटे हैं, तो आप पहले स्थान पर कभी नहीं रहे।

अब, प्रोग्रामर की उम्र के संकेतक के अलावा प्राचीन प्रोग्रामिंग भाषाओं की पृष्ठभूमि बहुत उपयोगी नहीं हो सकती है। इसके बावजूद, छोटे प्रोग्रामर में इस पृष्ठभूमि का अभाव होता है, इसलिए वे उस संदेश को नहीं समझ पाते हैं, जिस समय इसे पेश किया गया था, इस स्लोगन को "गोटो को हानिकारक माना जाता है" ।

नारे लगाने वाले को समझ में नहीं आता कि बहुत रोशन नहीं हैं। ऐसे नारों को भूलना शायद सबसे अच्छा है। इस तरह के नारे मदद नहीं करते।

यह विशेष रूप से नारा है, "गोटो हानिकारक माना जाता है," अपने स्वयं के एक मरे हुए जीवन पर ले लिया है।

क्या गोटो का दुरुपयोग नहीं हो सकता है? उत्तर: निश्चित, लेकिन ऐसा क्या? व्यावहारिक रूप से हर प्रोग्रामिंग तत्व का दुरुपयोग किया जा सकता है। boolउदाहरण के लिए विनम्र को अधिक बार दुर्व्यवहार किया जाता है, हममें से कुछ लोग विश्वास करना चाहेंगे।

इसके विपरीत, मुझे 1990 के बाद से गोटो के दुरुपयोग का एक भी वास्तविक उदाहरण मिलना याद नहीं है।

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

आज गोटो की सबसे बुरी बात यह है कि इसका पर्याप्त उपयोग नहीं किया जाता है।

— THB
स्रोत
24

जे बल्लू द्वारा उत्तर देने से आकर्षित होकर, मैं अपना £ 0.02 जोड़ूंगा। यदि ब्रूनो रैन्शर्ट पहले से ही ऐसा नहीं करते थे, तो मैंने नेथ के "संरचित प्रोग्रामिंग विद गोटो स्टेटमेंट्स" लेख का उल्लेख किया है।

एक बात जो मैंने चर्चा में नहीं देखी है, वह कोड की तरह है, जो कि बिल्कुल सामान्य नहीं है, जबकि फोरट्रान पाठ पुस्तकों में पढ़ाया जाता था। डीओ लूप और ओपन-कोडेड सबरूटीन्स की विस्तारित सीमा जैसी चीजें (याद रखें, यह फोरट्रान II, या फोरट्रान IV, या फोरट्रान 66 - फोरट्रान 77 या 90 नहीं होगी)। कम से कम एक मौका है कि वाक्यविन्यास विवरण अक्षम हैं, लेकिन अवधारणाएं पर्याप्त सटीक होनी चाहिए। प्रत्येक मामले में स्निपेट एकल फ़ंक्शन के अंदर होते हैं।

ध्यान दें कि कर्निघन एंड प्लेंजर की उत्कृष्ट लेकिन दिनांकित (और प्रिंट आउट) पुस्तक ' एलिमेंट्स ऑफ़ प्रोग्रामिंग स्टाइल, 2 डी एडन' में अपने युग की प्रोग्रामिंग टेक्स्ट बुक्स (70 के दशक) से गोटो के दुरुपयोग के कुछ वास्तविक जीवन के उदाहरण शामिल हैं। नीचे दी गई सामग्री उस पुस्तक से नहीं है, हालांकि।

डीओ लूप के लिए विस्तारित सीमा

       do 10 i = 1,30
           ...blah...
           ...blah...
           if (k.gt.4) goto 37
91         ...blah...
           ...blah...
10     continue
       ...blah...
       return
37     ...some computation...
       goto 91

इस तरह के बकवास का एक कारण पुराने जमाने के पंच-कार्ड थे। आप देख सकते हैं कि लेबल (क्रम से बाहर निकलना क्योंकि वह विहित शैली है!) कॉलम 1 में हैं (वास्तव में, उन्हें 1-5 कॉलम में होना था) और कोड कॉलम 7-72 ​​में है (कॉलम 6 निरंतरता था मार्कर कॉलम)। 73-80 कॉलम में एक क्रम संख्या दी जाएगी, और ऐसी मशीनें थीं जो क्रम संख्या क्रम में पंच कार्ड डेक को सॉर्ट करेंगी। यदि आपके पास अनुक्रमित कार्ड पर आपका कार्यक्रम था और लूप के बीच में कुछ कार्ड (लाइनें) जोड़ने की आवश्यकता थी, तो आपको उन अतिरिक्त लाइनों के बाद सब कुछ वापस करना होगा। हालाँकि, यदि आपने एक कार्ड को गोटो सामान के साथ बदल दिया है, तो आप सभी कार्डों को फिर से तैयार करने से बच सकते हैं - आपने नए अनुक्रम संख्याओं के साथ रूटीन के अंत में नए कार्डों को टक किया। इसे 'ग्रीन कंप्यूटिंग' का पहला प्रयास मानें

ओह, आप यह भी नोट कर सकते हैं कि मैं धोखा दे रहा हूं और चिल्ला नहीं रहा हूं - फोरट्रान IV सामान्य रूप से सभी ऊपरी मामलों में लिखा गया था।

ओपन-कोडेड सबरूटीन

       ...blah...
       i = 1
       goto 76
123    ...blah...
       ...blah...
       i = 2
       goto 76
79     ...blah...
       ...blah...
       goto 54
       ...blah...
12     continue
       return
76     ...calculate something...
       ...blah...
       goto (123, 79) i
54     ...more calculation...
       goto 12

76 और 54 लेबल के बीच का GOTO कंप्यूटेड गोटो का एक संस्करण है। यदि चर का मान 1 है, तो सूची में पहला लेबल गोटो (123); यदि इसका मान 2 है, तो गोटो दूसरा है, और इसी तरह। 76 से गणना किए गए गोटो का टुकड़ा खुले-कोडित सबरूटीन है। यह एक सबरूटीन की तरह निष्पादित कोड का एक टुकड़ा था, लेकिन एक फ़ंक्शन के शरीर में लिखा गया था। (फोरट्रान के कथन कार्य भी थे - जो कि एक पंक्ति में लगे हुए एम्बेडेड कार्य थे।)

गणना किए गए गोटो की तुलना में बदतर निर्माण थे - आप चर को लेबल असाइन कर सकते हैं और फिर एक निर्धारित गोटो का उपयोग कर सकते हैं। गोगलिंग को सौंपा गया गोटो बताता है कि इसे फोरट्रान 95 से हटा दिया गया था। संरचित प्रोग्रामिंग क्रांति के लिए चाक एक है जिसे काफी हद तक डिक्जस्ट्रा के "गोटो कंसीडरेड हार्मफुल" पत्र या लेख के साथ सार्वजनिक रूप से शुरू किया जा सकता है।

फोर्ट्रान में (और अन्य भाषाओं में, जिनमें से अधिकांश सही तरीके से गिर गए हैं) चीजों के प्रकार के कुछ ज्ञान के बिना, हमारे लिए नए लोगों के लिए उस समस्या के दायरे को समझना मुश्किल है, जो दिजाकस्ट्रा के साथ काम कर रहा था। हेक, मैंने उस पत्र के प्रकाशित होने के दस साल बाद तक प्रोग्रामिंग शुरू नहीं की थी (लेकिन मुझे कुछ समय के लिए फोरट्रान IV में कार्यक्रम करने का दुर्भाग्य था)।

— जोनाथन लेफ़लर को दर्शाता है
स्रोत
2
यदि आप goto'वाइल्ड ’में कुछ कोड का उदाहरण देखना चाहते हैं , तो प्रश्न वांटेड: वर्किंग बोस-हिबर्ड सॉर्ट एलगोरिदम 1963 में प्रकाशित कुछ (अल्गोल 60) कोड दिखाता है। मूल लेआउट आधुनिक कोडन मानकों की तुलना नहीं करता है। स्पष्ट (इंडेंटेड) कोड अभी भी काफी असंवेदनशील है। gotoबयान वहाँ कर इसे समझने की (बहुत) कठिन क्या एल्गोरिथ्म पर निर्भर है बनाते हैं।
— जोनाथन लेफ्लर
1
पंच कार्ड के करीब कुछ भी अनुभव करने के लिए युवा होने के नाते, यह फिर से छिद्रण समस्या के बारे में पढ़ने के लिए ज्ञानवर्धक था। +1
— Qix - मोनासा 3
20

GOTO के हानिकारक होने जैसी कोई बात नहीं है ।

GOTO एक उपकरण है, और सभी उपकरणों के रूप में, इसका उपयोग और दुरुपयोग किया जा सकता है ।

हालाँकि, प्रोग्रामिंग दुनिया में कई उपकरण हैं जिनका उपयोग करने की तुलना में अधिक दुरुपयोग किया जाने की प्रवृत्ति है , और गोटो उनमें से एक है। साथ डेल्फी के बयान एक और है।

व्यक्तिगत रूप से मैं या तो विशिष्ट कोड में उपयोग नहीं करता हूं , लेकिन मैंने दोनों GOTO का विषम उपयोग किया है और उसके साथ वारंट किया गया था , और एक वैकल्पिक समाधान में अधिक कोड शामिल होगा।

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

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

— लासे वी। कार्लसन
स्रोत
जीओटीओ के साथ समस्या यह है कि यह महत्वपूर्ण हमलावरों को तोड़ देता है जिन्हें हम आधुनिक प्रोग्रामिंग भाषाओं के साथ प्रदान करते हैं। एक उदाहरण लेने के लिए, यदि मैं किसी फ़ंक्शन को कॉल करता हूं, तो हम मान लेते हैं कि जब फ़ंक्शन पूरा हो जाता है, तो यह कॉलर को या तो सामान्य रूप से या असाधारण स्टैक अनइंडिंग के माध्यम से नियंत्रण वापस कर देगा। यदि वह फ़ंक्शन GOTO का गलत उपयोग करता है, तो निश्चित रूप से यह अब सच नहीं है। इससे हमारे कोड के बारे में तर्क करना बहुत मुश्किल हो जाता है। GOTO के गलत उपयोग से बचने के लिए यह पर्याप्त नहीं है। समस्या तब भी होती है यदि GOTO का हमारे आश्रितों द्वारा दुरुपयोग किया जाता है ...
— जोनाथन हार्टले
... इसलिए यह जानने के लिए कि क्या हम अपने फ़ंक्शन कॉल के बारे में तर्क दे सकते हैं, हमें अपनी हर एक सकर्मक निर्भरता के स्रोत कोड की प्रत्येक पंक्ति की जांच करने की आवश्यकता है, यह जाँचते हुए कि वे GOTO का दुरुपयोग नहीं करते हैं। तो बस भाषा में जीओटीओ के अस्तित्व ने हमारे कोड के बारे में आत्मविश्वास से तर्क करने की हमारी क्षमता को तोड़ दिया है, भले ही हम इसे पूरी तरह से उपयोग करें (या कभी भी इसका उपयोग न करें)। इस कारण से, GOTO केवल सावधानीपूर्वक उपयोग किया जाने वाला उपकरण नहीं है। यह व्यवस्थित रूप से टूटा हुआ है और एक भाषा में इसका अस्तित्व एकतरफा हानिकारक माना जाता है।
— जोनाथन हार्टले
यहां तक ​​कि अगर gotoकीवर्ड को C # से स्क्रब किया गया था, तो भी "यहां कूदने" की अवधारणा IL में मौजूद है। गोटो कीवर्ड के बिना एक अनंत लूप आसानी से बनाया जा सकता है। यदि इस गारंटी की कमी है कि बुलाया कोड वापस आ जाएगा, आपकी राय में, "कोड के बारे में तर्क करने में असमर्थ" का मतलब है, तो मैं कहूंगा कि हमारे पास कभी भी यह क्षमता नहीं थी।
— लास वी। कार्लसन
आह, आपने हमारी गलतफहमी का स्रोत पाया है। gotoसी में # एक असली "गोटो" शब्द का मूल अर्थ में नहीं है। यह एक बहुत कमजोर संस्करण है जो केवल एक फ़ंक्शन के भीतर कूदने की अनुमति देता है। जिस अर्थ में मैं "गोटो" का उपयोग कर रहा हूं वह प्रक्रिया में कहीं भी कूदने की अनुमति देता है। इसलिए हालांकि C # में एक "गोटो" कीवर्ड है, यह यकीनन कभी भी वास्तविक गोटो नहीं रहा है। हां, एक असली गोटो आईएल स्तर पर उपलब्ध है, उसी तरह जब यह किसी भी भाषा को विधानसभा के लिए संकलित किया जाता है। लेकिन प्रोग्रामर उस से परिरक्षित है, सामान्य परिस्थितियों में इसका उपयोग करने में असमर्थ है, इसलिए यह गिनती नहीं करता है।
— जोनाथन हार्टले
संयोग से, मैं यहाँ जो वर्णन कर रहा हूँ, वह मूल रूप से मेरा नहीं है, लेकिन १ ९ ६ re से दिक्जस्त्र के मूल पत्र का मूल है, मुझे लगता है, उसके संपादक "गोटो को हानिकारक" के रूप में फिर से शीर्षक दिया गया है, जो कि ५० के लिए इस तरह का एक उद्धरण-आधारित मेम बन गया है साल ठीक है क्योंकि यह बहुत क्रांतिकारी, व्यावहारिक और सार्वभौमिक रूप से स्वीकार किया गया था।
— जोनाथन हार्टले
17

यह कभी नहीं था, जब तक आप अपने लिए सोचने में सक्षम थे।

— stesch
स्रोत
17

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

मैंने कोड लिखा है जो केवल एक बार setjmp / longjmp का उपयोग करता है। यह मिडी ड्रम सीक्वेंसर कार्यक्रम में था। प्लेबैक सभी उपयोगकर्ता इंटरैक्शन से एक अलग प्रक्रिया में हुआ, और प्लेबैक प्रक्रिया ने यूआई प्रक्रिया के साथ साझा की गई मेमोरी का उपयोग किया जो कि सीमित जानकारी को प्लेबैक करने के लिए आवश्यक थी। जब उपयोगकर्ता प्लेबैक को रोकना चाहता था, तो प्लेबैक प्रक्रिया ने एक लॉन्गजम्प को शुरू करने के लिए "बैक टू द स्टार्ट" किया, बजाय इसके कि जहां उपयोगकर्ता इसे रोकना चाहता था, वहां कुछ जटिल अनइंडिंग निष्पादित हो। यह महान काम करता था, सरल था, और मुझे उस उदाहरण में इससे संबंधित कोई समस्या या कीड़े नहीं थे।

setjmp / longjmp में अपना स्थान होता है - लेकिन वह स्थान वह है जिसकी आप यात्रा नहीं करेंगे लेकिन एक बार बहुत लंबे समय में।

संपादित करें: मैंने अभी कोड देखा। यह वास्तव में siglongjmp () था जो मैंने इस्तेमाल किया था, न कि longjmp (ऐसा नहीं है कि यह एक बड़ी बात है, लेकिन मैं यह भूल गया था कि siglongjmp भी मौजूद था।)

— रेव्ह स्मरकेरॉन
स्रोत
15

यदि आप C में VM लिख रहे हैं, तो यह पता चलता है कि (gcc के) कम्प्यूटेड गन का उपयोग इस तरह किया जाता है:

char run(char *pc) {
    void *opcodes[3] = {&&op_inc, &&op_lda_direct, &&op_hlt};
    #define NEXT_INSTR(stride) goto *(opcodes[*(pc += stride)])
    NEXT_INSTR(0);
    op_inc:
    ++acc;
    NEXT_INSTR(1);
    op_lda_direct:
    acc = ram[++pc];
    NEXT_INSTR(1);
    op_hlt:
    return acc;
}

लूप के अंदर पारंपरिक स्विच की तुलना में बहुत तेजी से काम करता है।

— vt।
स्रोत
केवल समस्या, कि यह मानक नहीं है, है?
— कैलमेरियस
&&op_incनिश्चित रूप से संकलन नहीं करता है, क्योंकि (बाएं) &एक अंतराल की अपेक्षा करता है, लेकिन (दाएं) &एक अंतराल पैदा करता है।
— फ्रेडओवरफ्लो
7
@ फ़्रेडो: यह एक विशेष जीसीसी ऑपरेटर है। हालाँकि, मैं इस कोड को सभी परिस्थितियों में अस्वीकार कर दूंगा, क्योंकि मैं सबसे अधिक स्पष्ट रूप से डब्ल्यूटीएफ के बारे में नहीं समझ सकता।
— पिल्ला
हालांकि यह एक उदाहरण है (गति के लिए अधिकतम अनुकूलन) जो गोटो और क्रिप्टिक कोड दोनों के उपयोग को सही ठहराता है, फिर भी अनुकूलन की आवश्यकता को समझाने के लिए अत्यधिक टिप्पणी की जानी चाहिए, मोटे तौर पर यह कैसे काम करता है, और सबसे अच्छा लाइन-बाय-लाइन टिप्पणियाँ जो की जा सकती हैं। तो, यह अभी भी विफल रहता है, लेकिन क्योंकि यह रखरखाव प्रोग्रामर को अंधेरे में छोड़ देता है। लेकिन मुझे VM उदाहरण पसंद है। धन्यवाद।
— माइक्रोसेरोऑनडीडी
14

क्योंकि gotoमेटाप्रोग्रामिंग को भ्रमित करने के लिए इस्तेमाल किया जा सकता है

Gotoदोनों एक उच्च-स्तरीय और निम्न-स्तरीय नियंत्रण अभिव्यक्ति है, और इसके परिणामस्वरूप ज्यादातर समस्याओं के लिए उपयुक्त डिज़ाइन पैटर्न नहीं है।

यह इस अर्थ में निम्न-स्तर है कि एक गोटो एक आदिम संचालन है जो कुछ उच्चतर whileया जैसे कुछ को लागू करता foreachहै।

यह इस अर्थ में उच्च-स्तर है कि जब कुछ निश्चित तरीकों से उपयोग किया जाता है तो यह एक स्पष्ट अनुक्रम में निष्पादित कोड लेता है, एक निर्बाध फैशन में, संरचित छोरों को छोड़कर, और यह इसे तर्क के टुकड़ों में बदल देता है, जो पर्याप्त gotoएस के साथ हैं , एक अवशोषित - तर्क का गतिशील रूप से पुन: संयोजन किया जा रहा है।

तो, वहाँ एक कानूनी और एक बुराई पक्ष है goto।

नीरस पक्ष है कि एक ऊपर की ओर इशारा गोटो एक पूरी तरह से उचित पाश लागू कर सकते हैं और एक नीचे की दिशा गोटो एक पूरी तरह से उचित क्या कर सकते हैं breakया return। बेशक, एक वास्तविक while, breakया returnबहुत अधिक पठनीय होगा, क्योंकि गरीब मानव को gotoबड़ी तस्वीर प्राप्त करने के लिए उसके प्रभाव का अनुकरण नहीं करना होगा । तो, सामान्य रूप से एक बुरा विचार है।

बुराई की ओर एक नियमित जबकि, विकृत या वापसी के लिए गोटो का उपयोग नहीं है, लेकिन क्या कहते हैं के लिए उपयोग शामिल है स्पेगेटी तर्क । इस मामले में गोटो-हैप्पी डेवलपर, गोटो के चक्रव्यूह के बाहर कोड के टुकड़ों का निर्माण कर रहा है, और इसे समझने का एकमात्र तरीका यह है कि इसे मानसिक रूप से एक पूरे के रूप में अनुकरण किया जाए, जब बहुत से गोटो हैं। मेरा मतलब है, कोड के मूल्यांकन की परेशानी की कल्पना करना, जहां elseवास्तव में इसका उलटा नहीं है if, जहां नेस्टेड ifएस कुछ चीजों में अनुमति दे सकता है जो बाहरी if, आदि द्वारा अस्वीकार कर दिए गए थे ।

अंत में, वास्तव में विषय को कवर करने के लिए, हमें ध्यान देना चाहिए कि मूल रूप से अल्गोल को छोड़कर सभी प्रारंभिक भाषाओं ने शुरू में अपने संस्करणों के विषय में केवल एक ही बयान दिया था if-then-else। तो, एक सशर्त ब्लॉक करने का एकमात्र तरीका gotoउलटा सशर्त का उपयोग करके इसके चारों ओर था । पागल, मुझे पता है, लेकिन मैंने कुछ पुराने चश्मे पढ़े हैं। याद रखें कि पहले कंप्यूटर को बाइनरी मशीन कोड में प्रोग्राम किया गया था, इसलिए मुझे लगता है कि किसी भी तरह का एचएलएल एक लाइफसेवर था; मुझे लगता है कि वे वास्तव में एचएलएल सुविधाओं के बारे में बहुत चुस्त नहीं थे।

यह सब कहने के बाद कि मैं gotoहर कार्यक्रम में एक छड़ी रखता था जो मैंने लिखा था "बस शुद्धतावादियों को नाराज करना" ।

— DigitalRoss को दर्शाता है
स्रोत
4
शुद्धतावादियों को परेशान करने के लिए +1! :-)
— लुमी
10

प्रोग्रामर को GOTO स्टेटमेंट के उपयोग से इनकार करना एक बढ़ई को हथौड़ा का उपयोग न करने के लिए कहने जैसा है क्योंकि यह दीवार को नुकसान पहुंचा सकता है जबकि वह एक कील में हथौड़ा मार रहा है। एक वास्तविक प्रोग्रामर GOTO का उपयोग कैसे और कब करता है, यह जानता है। मैंने इनमें से कुछ तथाकथित 'स्ट्रक्चर्ड प्रोग्राम्स' के पीछे पीछा किया है, मैंने एक GOTO का उपयोग करने से बचने के लिए ऐसे डरावने कोड देखे हैं, जिससे मैं प्रोग्रामर को गोली मार सकता था। ठीक है, दूसरी तरफ के बचाव में, मैंने कुछ वास्तविक स्पेगेटी कोड भी देखे हैं और फिर से, उन प्रोग्रामर को भी गोली मार दी जानी चाहिए।

यहाँ मैंने पाया कोड का सिर्फ एक छोटा सा उदाहरण है।

  YORN = ''
  LOOP
  UNTIL YORN = 'Y' OR YORN = 'N' DO
     CRT 'Is this correct? (Y/N) : ':
     INPUT YORN
  REPEAT
  IF YORN = 'N' THEN
     CRT 'Aborted!'
     STOP
  END

----------------------- या ----------------------

10:  CRT 'Is this Correct (Y)es/(N)o ':

     INPUT YORN

     IF YORN='N' THEN
        CRT 'Aborted!'
        STOP
     ENDIF
     IF YORN<>'Y' THEN GOTO 10
— कर्टटम्पा
स्रोत
3
DO CRT 'क्या यह सही है? (Y / N): ': INPUT YORN UNTIL YORN =' Y 'OR YORN =' N '; आदि
— joel.neely
5
वास्तव में, लेकिन इससे भी महत्वपूर्ण बात, एक वास्तविक प्रोग्रामर जानता है कि कब - का उपयोग नहीं करना चाहिए gotoऔर क्यों पता है । वर्जित भाषा निर्माण से बचना क्योंकि $ प्रोग्रामिंग_गुरु ने ऐसा कहा, यह कार्गो-पंथ प्रोग्रामिंग की बहुत परिभाषा है।
— पिस्कोर ने बिल्डिंग
1
यह एक अच्छा सादृश्य है। सब्सट्रेट को नुकसान पहुँचाए बिना एक कील ड्राइव करने के लिए, आप हथौड़ा को खत्म नहीं करते हैं। बल्कि, आप एक साधारण उपकरण का उपयोग करते हैं जिसे नेल पंच के रूप में जाना जाता है। यह एक टेप के साथ एक धात्विक पिन है जिसकी नोक पर एक खोखला इंडेंटेशन है, नाखून के सिर के साथ सुरक्षित रूप से युगल (ये उपकरण विभिन्न नाखूनों के लिए अलग-अलग आकार में आते हैं)। नाखून पंच का दूसरा, कुंद छोर हथौड़े से मारा जाता है।
— कज़
9

"इस लिंक में http://kerneltrap.org/node/553/2131 "

विडंबना यह है कि गोटो को हटाकर एक बग की शुरुआत की गई: स्पिनक कॉल को छोड़ दिया गया।

— जय बल्लू
स्रोत
+1 के लिए 'गोटो को हटाने के लिए एक बग की शुरुआत की'
— QED
7

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

— जॉन मिलिकिन
स्रोत
6

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

उदाहरण के लिए, यदि आप संसाधनों को हड़प रहे हैं और सेमीफोर या म्यूटेक्स का उपयोग कर रहे हैं, तो आपको उन्हें क्रम में पकड़ना होगा और आपको हमेशा उन्हें विपरीत तरीके से छोड़ना चाहिए।

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

यह हमेशा गोटो के बिना सही करना संभव है, लेकिन इस मामले में और कुछ अन्य गोटो वास्तव में पठनीयता और स्थिरता के लिए मुख्य रूप से बेहतर समाधान है।

-Adam

— एडम डेविस
स्रोत
5

पैदावार वापसी द्वारा परिभाषित प्रगणकों के लिए राज्य मशीनों को बनाने के लिए C # संकलक द्वारा एक आधुनिक GOTO उपयोग है।

GOTO एक ऐसी चीज है जिसका उपयोग संकलक द्वारा किया जाना चाहिए न कि प्रोग्रामर द्वारा।

— ब्रायन लिआ
स्रोत
5
आपको क्या लगता है कि संकलक कौन बनाता है?
— 19
10
संकलक, बिल्कुल!
— सिटी २।
3
मुझे लगता है कि उनका मतलब है "गोटो एक ऐसी चीज है जिसका उपयोग केवल एक कंपाइलर द्वारा उत्सर्जित कोड द्वारा किया जाना चाहिए"।
— सिमोन बुकान
यह एक मामला है goto। जहां हम gotoकिसी एन्यूमरेटर को लागू करने के लिए हाथ से कोडित एक स्टेट-मशीन में उपयोग कर सकते हैं, हम yieldइसके बजाय सिर्फ उपयोग कर सकते हैं ।
— जॉन हैना
डिफ़ॉल्ट स्टेटमेंट के साथ कई स्ट्रिंग पर स्विच (यदि-और के लिए संकलित करने के लिए) गोटो स्टेटमेंट के साथ स्विच करने के लिए संकलित करता है।
— एमकाज़म अखगीरी
5

जब तक C और C ++ (अन्य दोषियों के बीच) में विराम के लेबल हैं और जारी रहता है, तब तक गोटो की भूमिका बनी रहेगी।

— DrPizza
स्रोत
तो लेबल विच्छेद या जारी रखना गोटो से अलग होगा कैसे?
— मैथ्यू Whited
3
वे नियंत्रण प्रवाह में पूरी तरह से मनमाना कूदने की अनुमति नहीं देते हैं।
— 21
5

यदि GOTO स्वयं ही दुष्ट थे, तो संकलक बुराई करेंगे, क्योंकि वे JMP उत्पन्न करते हैं। यदि कोड के एक ब्लॉक में कूदना, विशेष रूप से एक सूचक का अनुसरण करना, स्वाभाविक रूप से बुराई थे, तो रीटर्न निर्देश बुराई होगा। बल्कि, बुराई दुरुपयोग की क्षमता में है।

कई बार मुझे ऐसे ऐप्स लिखने पड़ते हैं, जिनमें कई ऑब्जेक्ट्स पर नज़र रखनी होती है, जहाँ घटनाओं के जवाब में प्रत्येक ऑब्जेक्ट को राज्यों के जटिल अनुक्रम का पालन करना होता है, लेकिन पूरी बात निश्चित रूप से सिंगल-थ्रेड थी। राज्यों का एक विशिष्ट अनुक्रम, यदि छद्म कोड में प्रतिनिधित्व किया जाएगा:

request something
wait for it to be done
while some condition
    request something
    wait for it
    if one response
        while another condition
            request something
            wait for it
            do something
        endwhile
        request one more thing
        wait for it
    else if some other response
        ... some other similar sequence ...
    ... etc, etc.
endwhile

मुझे यकीन है कि यह नया नहीं है, लेकिन जिस तरह से मैंने इसे सी (++) में संभाला वह कुछ मैक्रोज़ को परिभाषित करने के लिए था:

#define WAIT(n) do{state=(n); enque(this); return; L##n:;}while(0)
#define DONE state = -1

#define DISPATCH0 if state < 0) return;
#define DISPATCH1 if(state==1) goto L1; DISPATCH0
#define DISPATCH2 if(state==2) goto L2; DISPATCH1
#define DISPATCH3 if(state==3) goto L3; DISPATCH2
#define DISPATCH4 if(state==4) goto L4; DISPATCH3
... as needed ...

तब (स्थिति संभालने के बाद शुरू में 0 है) ऊपर संरचित राज्य मशीन संरचित कोड में बदल जाती है:

{
    DISPATCH4; // or as high a number as needed
    request something;
    WAIT(1); // each WAIT has a different number
    while (some condition){
        request something;
        WAIT(2);
        if (one response){
            while (another condition){
                request something;
                WAIT(3);
                do something;
            }
            request one more thing;
            WAIT(4);
        }
        else if (some other response){
            ... some other similar sequence ...
        }
        ... etc, etc.
    }
    DONE;
}

इस पर भिन्नता के साथ, CALL और RETURN हो सकते हैं, इसलिए कुछ राज्य मशीनें अन्य राज्य मशीनों के सबरूटीन की तरह काम कर सकती हैं।

क्या यह असामान्य है? हाँ। क्या यह अनुरक्षक की ओर से कुछ सीख लेता है? हाँ। क्या वह सीख चुकता है? मुझे ऐसा लगता है। क्या यह GOTOs के बिना किया जा सकता है जो ब्लॉकों में कूदते हैं? नहीं।

— माइक डनलवे का पता चलता है
स्रोत
1
डर से भाषा की विशेषता से बचना मस्तिष्क क्षति का संकेत है। यह भी नर्क से नफ़रत है।
— वेक्टर गोरगोथ
4

मैं इससे बचता हूं क्योंकि एक सहकर्मी / प्रबंधक निस्संदेह एक कोड समीक्षा में या जब वे इस पर ठोकर खाते हैं तो इसके उपयोग पर सवाल उठाएंगे। जबकि मुझे लगता है कि इसका उपयोग होता है (उदाहरण के लिए त्रुटि से निपटने का मामला) - आप कुछ अन्य डेवलपर के साथ चलेंगे, जिन्हें इसके साथ कुछ प्रकार की समस्या होगी।

यह इसके लायक नहीं है।

— दर्शाता है
स्रोत
Try ... के बारे में अच्छी बात यह है कि C # में ब्लॉक पकड़ो कि वे स्टैक और अन्य आवंटित संसाधनों की सफाई का ध्यान रखते हैं (जिन्हें स्टैक को खोलना कहा जाता है) एक अपवाद हैंडलर तक अपवाद बुलबुले के रूप में। यह एक कोशिश करता है ... गोटो से बहुत बेहतर पकड़ो, इसलिए यदि आपके पास कोशिश है ... पकड़ो, इसका उपयोग करें।
— स्कॉट व्हिटलॉक
मेरे पास एक बेहतर उपाय है: कोड के उस टुकड़े को लपेटें जिसे आप 'do {...} से बाहर पॉप करना चाहते हैं (0);' पाश। इस तरह, आप कोशिश / कैच लूप के ओवरहेड के बिना एक गोटो के रूप में उसी तरह से कूद सकते हैं (मुझे सी # के बारे में नहीं पता है, लेकिन सी ++ में कोशिश कम लागत वाली है और पकड़ उच्च लागत वाली है, इसलिए ऐसा लगता है एक साधारण छलांग पर्याप्त होगा जहां एक अपवाद को फेंकने के लिए)।
— जिम डोवे
10
जिम, उस के साथ समस्या यह है कि यह गदहे प्राप्त करने के एक मूर्खतापूर्ण गोल चक्कर रास्ते से ज्यादा कुछ नहीं है।
— स्टाइल
4

मैंने वास्तव में खुद को एक गोटो का उपयोग करने के लिए मजबूर पाया, क्योंकि मैं सचमुच इस कोड को लिखने के लिए बेहतर (तेज़) तरीके के बारे में नहीं सोच सकता:

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

SomeObject someObject;    

if (someObject.IsComplex())    // this test is trivial
{
    // begin slow calculations here
    if (result of calculations)
    {
        // just discovered that I could use the fast calculation !
        goto Fast_Calculations;
    }
    // do the rest of the slow calculations here
    return;
}

if (someObject.IsmediumComplex())    // this test is slightly less trivial
{
    Fast_Calculations:
    // Do fast calculations
    return;
}

// object is simple, no calculations needed.

यह वास्तविक समय यूआई कोड के एक गति महत्वपूर्ण टुकड़े में था, इसलिए मुझे ईमानदारी से लगता है कि यहां एक GOTO को उचित ठहराया गया था।

ह्यूगो

— Rocketmagnet
स्रोत
गैर-जीओटीओ तरीका एक फास्ट_क्यूलस फ़ंक्शन का उपयोग करना होगा, जो कुछ ओवरहेड को उकसाता है। संभवतः अधिकांश परिस्थितियों में ध्यान देने योग्य नहीं है, लेकिन जैसा कि आपने कहा कि यह गति-महत्वपूर्ण था।
— काइल क्रोनिन
1
वैसे यह शायद ही आश्चर्यजनक है। सभी कोड जिसमें बिल्कुल पागल प्रदर्शन दिशानिर्देश हैं, हमेशा सभी सर्वोत्तम प्रथाओं को बहुत अधिक तोड़ देंगे। सर्वोत्तम अभ्यास पुनर्संयोजन और रखरखाव के लिए हैं, 10 अधिक मिलीसेकंड निचोड़ने या 5 बाइट्स अधिक राम को बचाने के लिए नहीं।
— जोनाथन
1
@JonathonWisnoski, गोटो के वैध उपयोगों से यह भी पता चलता है कि जहाँ हम जा रहे हैं, वहाँ नज़र रखने के लिए एक चूहे के घोंसले के साथ स्पेगेटी कोड की पागल मात्रा को खत्म करते हैं।
— वॉनब्रांड
4

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

मैं व्यक्तिगत रूप से कभी भी इसका स्पष्ट रूप से उपयोग नहीं करता हूं, कभी भी इसकी आवश्यकता नहीं है।

— एडम हल्ड्सवर्थ
स्रोत
4

एक बात जो मैंने यहाँ किसी भी उत्तर से नहीं देखी है, वह यह है कि एक 'गेटो' समाधान अक्सर संरचित प्रोग्रामिंग प्रोग्रामों में से एक की तुलना में अधिक कुशल होता है।

कई नेस्टेड-लूप केस पर विचार करें, जहां if(breakVariable)वर्गों के एक समूह के बजाय 'गोटो' का उपयोग करना स्पष्ट रूप से अधिक कुशल है। समाधान "अपने छोरों को एक फ़ंक्शन में रखें और रिटर्न का उपयोग करें" अक्सर पूरी तरह से अनुचित है। इस संभावना के मामले में कि लूप स्थानीय चर का उपयोग कर रहे हैं, आपको अब उन सभी को फ़ंक्शन मापदंडों के माध्यम से पारित करना होगा, संभावित रूप से अतिरिक्त सिरदर्द के भार को संभालना होगा जो उससे उत्पन्न होते हैं।

अब क्लीनअप केस पर विचार करें, जिसे मैंने खुद काफी बार इस्तेमाल किया है, और यह इतना सामान्य है कि संभवत: कई भाषाओं में उपलब्ध {} कैच {} स्ट्रक्चर के लिए जिम्मेदार नहीं है। एक ही चीज़ को पूरा करने के लिए आवश्यक चेक और अतिरिक्त चर की संख्या जंप करने के लिए एक या दो निर्देशों की तुलना में कहीं अधिक खराब है, और फिर से, अतिरिक्त फ़ंक्शन समाधान बिल्कुल भी समाधान नहीं है। आप मुझे यह नहीं बता सकते हैं कि अधिक प्रबंधनीय या अधिक पठनीय है।

अब कोड स्थान, स्टैक का उपयोग, और निष्पादन का समय कई प्रोग्रामर के लिए कई स्थितियों में पर्याप्त नहीं हो सकता है, लेकिन जब आप कोड वातावरण में केवल 2KB के साथ काम करने के लिए एक एम्बेडेड वातावरण में हों, तो एक स्पष्ट रूप से परिभाषित न करने के लिए अतिरिक्त निर्देशों के 50 बाइट्स 'गोटो' सिर्फ हंसने योग्य है, और यह उतनी दुर्लभ स्थिति नहीं है, जितना कि कई उच्च-स्तरीय प्रोग्रामर मानते हैं।

यह कथन कि 'गोटो हानिकारक है' संरचित प्रोग्रामिंग की ओर बढ़ने में बहुत मददगार था, भले ही यह हमेशा सामान्यीकरण था। इस बिंदु पर, हम सभी ने इसे उपयोग करने से सावधान रहने के लिए पर्याप्त सुना है (जैसा कि हमें चाहिए)। जब यह स्पष्ट रूप से नौकरी के लिए सही उपकरण है, तो हमें इससे डरने की जरूरत नहीं है।

— gkimsey
स्रोत
3

आप इसे एक गहरी नेस्टेड लूप से तोड़ने के लिए उपयोग कर सकते हैं, लेकिन ज्यादातर समय आपके कोड को गहरी नेस्टेड लूप के बिना क्लीनर होने के लिए फिर से सक्रिय किया जा सकता है।

— ब्रायन आर बॉडी
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.