क्या गोटो का उपयोग करना कभी सार्थक है?


29

gotoलगभग सार्वभौमिक रूप से हतोत्साहित किया जाता है। क्या इस कथन का उपयोग करना कभी सार्थक है?



1
gotoसीपीयू आखिरकार क्या करता है, लेकिन यह ठीक से काम नहीं करता है कि लक्ष्य अंत पर कोई निशान नहीं होने के कारण मनुष्यों को समझने और अमूर्त करने की क्या आवश्यकता है। Intercal की तुलना करें COMEFROM

2
@ ThorbjørnRavnAndersen, जब कोई राज्य मशीन में राज्य के संक्रमण के बारे में बात कर रहा हो तो इंसानों का क्या मतलब है ? क्या आप एक समानता नहीं देख सकते हैं? "किसी दिए गए राज्य में जाएं ", इसका मतलब यह है कि और कुछ भी और कुछ नहीं बल्कि ऐसी तुच्छ चीज की एक अनावश्यक जटिलता होगी। और "नो मार्क" से आपका क्या मतलब है? लेबल एक ऐसा निशान है।
SK-तर्क

@ एसके-तर्क, इस बात पर निर्भर करता है कि आप कितनी दूर से गोटो को आने देंगे। राज्य मशीनों को कार्यान्वित करने के लिए गोटो की आवश्यकता नहीं होती है।

@ ThorbjørnRavnAndersen, निश्चित रूप gotoसे आवश्यक नहीं है। यह उन्हें अनिवार्य भाषाओं में लागू करने का सबसे तर्कसंगत तरीका है, क्योंकि यह राज्य संक्रमण के बहुत शब्दार्थों के सबसे करीब है। और इसका गंतव्य स्रोत से काफी दूर हो सकता है, यह पठनीयता में बाधा नहीं बनेगा। इस तरह के कोड का मेरा पसंदीदा उदाहरण डे नूथ का साहसिक खेल का कार्यान्वयन है।
एसके-तर्क 10

जवाबों:


49

यह स्टैक ओवरफ्लो पर कई बार चर्चा की गई है, और क्रिस गिलम ने इसके संभावित उपयोगों को संक्षेप में प्रस्तुत किया हैgoto :

सफाई से एक समारोह से बाहर निकलना

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

नेस्टेड छोरों से बाहर निकलना

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

निम्न स्तर के प्रदर्शन में सुधार

यह केवल परफेक्ट-क्रिटिकल कोड में मान्य है, लेकिन गोटो स्टेटमेंट बहुत तेज़ी से निष्पादित होते हैं और किसी फ़ंक्शन के माध्यम से आगे बढ़ने पर आपको बढ़ावा दे सकते हैं। हालांकि, यह एक दोधारी तलवार है, क्योंकि एक संकलक आमतौर पर कोड को ऑप्टिमाइज़ नहीं कर सकता है जिसमें गोटो शामिल हैं।

मैं तर्क देता हूं, जैसा कि कई अन्य लोग तर्क देते हैं, कि इन सभी मामलों में, का उपयोग gotoएक कोने में से एक को बाहर निकालने के लिए एक साधन के रूप में किया जाता है, और आमतौर पर कोड का एक लक्षण है जिसे फिर से सक्रिय किया जा सकता है।


28
पहली समस्या finallyआधुनिक भाषाओं में ब्लॉक द्वारा बहुत करीने से हल की गई है, और दूसरी लेबल breakएस द्वारा हल की गई है । यदि आप सी के साथ फंस गए हैं, gotoतो सुंदर तरीके से इन समस्याओं को हल करने का एकमात्र तरीका है।
चिन्मय कांची

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

4
@ चिनमय - अंत में केवल 1) आधुनिक भाषाओं पर लागू होता है जो उनके पास है और बी) आप ओवरहेड को सहन कर सकते हैं (अपवाद हैंडलिंग में एक ओवरहेड है।) अर्थात, finallyउन शर्तों के तहत उपयोग करना केवल मान्य है। बहुत दुर्लभ हैं, फिर भी वैध परिस्थितियां हैं जहां एक गोटू जाने का रास्ता है।
luis.espinal

21
ठीक है लोग ... क्या बिल्ली के बीच अंतर है break 3या break myLabelऔर goto myLabel। ओह, यह सही है सिर्फ कीवर्ड। यदि आप उपयोग कर रहे हैं break, continueया कुछ समान कीवर्ड आप का gotoउपयोग for, while, foreach, do/loopकर रहे हैं (यदि आप उपयोग कर रहे हैं तो आप एक सशर्त गोटो का उपयोग कर रहे हैं।)
मैथ्यू Whited

4
निम्न स्तर के प्रदर्शन के बारे में - आधुनिक प्रोसेसर का व्यवहार भविष्यवाणी करना मुश्किल हो सकता है (पाइपलाइन, आउट-ऑफ-ऑर्डर निष्पादन) इसलिए शायद 99% मामलों में यह इसके लायक नहीं है या यहां तक ​​कि यह धीमा भी हो सकता है। @ मैथ्यू वाइट: स्कोपिंग। यदि आप मनमाना बिंदु पर गुंजाइश दर्ज करते हैं, तो यह स्पष्ट नहीं है (मानव के लिए) क्या निर्माणकर्ताओं को बुलाया जाना चाहिए (समस्या सी में भी मौजूद है)।
मैकीज पीचोटका

42

उच्च-स्तरीय नियंत्रण प्रवाह निर्माण समस्या क्षेत्र में अवधारणाओं के अनुरूप होते हैं। एक / कुछ अन्य शर्त के आधार पर एक निर्णय है। एक पाश बार-बार कुछ कार्रवाई करने के लिए कहता है। यहां तक ​​कि एक ब्रेक स्टेटमेंट में कहा गया है "हम बार-बार ऐसा कर रहे थे, लेकिन अब हमें रोकने की जरूरत है"।

दूसरी ओर, एक गोटो स्टेटमेंट, रनिंग प्रोग्राम में एक कॉन्सेप्ट के अनुरूप होता है, समस्या क्षेत्र में नहीं। यह कार्यक्रम में एक निर्दिष्ट बिंदु पर निष्पादन जारी रखने के लिए कहता है । किसी कोड को पढ़ने के लिए है उसका अनुमान लगा समस्या डोमेन के संबंध में क्या है कि इसका मतलब है।

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

बाकी सभी समान हैं, कोड जिनकी संरचना दर्शाती है कि समस्या डोमेन को पढ़ने और बनाए रखने में आसान हो जाती है।

ऐसे कोई मामले नहीं हैं जहां एक गोटो बयान की आवश्यकता है ( उस प्रभाव के लिए एक प्रमेय है), लेकिन ऐसे मामले हैं जहां यह कम से कम बुरा समाधान हो सकता है। वे मामले भाषा से भाषा में भिन्न होते हैं, जो इस बात पर निर्भर करता है कि भाषा किस उच्च स्तर का निर्माण करती है।

सी में, उदाहरण के लिए, मेरा मानना ​​है कि तीन बुनियादी परिदृश्य हैं जहां एक गोटो उपयुक्त है।

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

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

एक उचित आधुनिक भाषा में गोटो का मुख्य उपयोग (यदि / / और छोरों का समर्थन करता है) भाषा से गायब होने वाले नियंत्रण प्रवाह निर्माण का अनुकरण करना है।


5
यह वास्तव में अब तक का सबसे अच्छा उत्तर है - आश्चर्य की बात है, एक सवाल के लिए जो डेढ़ साल पुराना है। :-)
कोनराड रुडोल्फ

1
+1 "अब तक का सर्वश्रेष्ठ उत्तर"। --- "यथोचित आधुनिक भाषा में गोटो का मुख्य उपयोग (जो / / और छोरों का समर्थन करता है) भाषा से गायब होने वाले नियंत्रण प्रवाह निर्माण का अनुकरण करना है।"
डेव डॉपसन

स्विच-स्टेट स्टेट मशीन में, कंट्रोल वैल्यू के लिए प्रत्येक राइट वास्तव में है goto। एसएसएसएम का उपयोग करने के लिए अक्सर अच्छी संरचनाएं होती हैं, क्योंकि वे एसएम राज्य को निष्पादन निर्माण से अलग करते हैं, लेकिन वे वास्तव में "गोटो" को समाप्त नहीं करते हैं।
सुपरकैट

2
"बाकी सभी समान हैं, कोड जिनकी संरचना दर्शाती है कि समस्या डोमेन को पढ़ने और बनाए रखने में आसान हो जाती है।" मैं इसे लंबे समय से पूरी तरह से जानता हूं, लेकिन इसमें शब्दों की कमी है, इसलिए इसे इस तरह से संवाद करना है कि अन्य प्रोग्रामर वास्तव में समझ सकें। इसके लिए शुक्रिया।
वाइल्डकार्ड

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

11

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

जावा ने इस समस्या को gotoपूरी तरह से समाप्त करके "हल" करने का प्रयास किया है । हालाँकि, जावा आपको returnएक finallyब्लॉक के अंदर उपयोग करने देता है और इस प्रकार अनजाने में एक अपवाद हो जाता है। वही समस्या अभी भी है: कंपाइलर अपना काम नहीं कर रहा है। gotoभाषा से हटाने से इसे ठीक नहीं किया गया है।

सी # में, gotoसुरक्षित के रूप में है break, continue, try/catch/finallyऔर return। यह आपको एकतरफा चर का उपयोग करने की अनुमति नहीं देता है, यह आपको अंततः ब्लॉक से बाहर कूदने नहीं देता है, आदि संकलक शिकायत करेंगे। ऐसा इसलिए है क्योंकि यह वास्तविक समस्या को हल करता है, जो ऐसा है जैसे मैंने कहा कि निरर्थक नियंत्रण प्रवाह। gotoजादुई रूप से निश्चित-असाइनमेंट विश्लेषण और अन्य उचित संकलक जांचों को रद्द नहीं करता है।


आपकी बात यह है कि C # gotoबुराई नहीं है? यदि ऐसा है, तो यह एक gotoनिर्माण के साथ हर नियमित रूप से इस्तेमाल की जाने वाली आधुनिक भाषा का मामला है , न केवल C # ...
lvella

9

हाँ। अपने छोरों गहरी कई स्तरों नेस्ट कर रहे हैं, gotoहै केवल सुंदर ढंग से एक आंतरिक लूप से बाहर तोड़ने के रास्ते। दूसरा विकल्प ध्वज सेट करना और प्रत्येक लूप को तोड़ना है यदि वह ध्वज किसी शर्त को पूरा करता है। यह वास्तव में बदसूरत है, और बहुत त्रुटि-प्रवण है। इन मामलों में, gotoबस बेहतर है।

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


किसी को भी नीचे की व्याख्या करने के लिए परवाह है? यह सवाल का पूरी तरह से वैध जवाब था ...
चिन्मय कांची

4
गोटो कभी एक सुंदर जवाब नहीं है। जब आपके छोरों को कई स्तरों पर घोंसला बनाया जाता है, तो आपकी समस्या यह है कि आप बहु कोडित छोरों से बचने के लिए अपने कोड को आर्किटेक्ट करने में विफल रहे। प्रक्रिया कॉल दुश्मन नहीं हैं। ("लैम्ब्डा: द अल्टीमेट ..." पेपर्स पढ़ें।) गोटो का उपयोग करके लूप से बाहर निकलने के लिए कई स्तरों पर नेस्टेड किया गया है, एक खुले कई फ्रैक्चर पर एक बैंड-सहायता डाल रहा है: यह सरल हो सकता है लेकिन यह सही नहीं है जवाब।
जॉन आर। स्ट्रॉहम

6
और हां, कभी भी अजीब मामला नहीं होता है जब गहरी नेस्टेड छोरों के लिए कहा जाता है? एक अच्छा प्रोग्रामर बनना नियमों का पालन करना ही नहीं है, बल्कि यह भी जानना है कि उन्हें कब तोड़ना है।
चिन्मय कांची 13

2
@ JohnR.Strohm कभी मत कहो। यदि आप प्रोग्रामिंग में "कभी नहीं" जैसे शब्दों का उपयोग करते हैं, तो आपने कोने के मामलों, अनुकूलन, संसाधन विरोधाभासों आदि से स्पष्ट रूप से निपटा नहीं है। गहरी नेस्टेड लूप्स में, गोटो वास्तव में छोरों से बाहर निकलने का सबसे साफ, सुरुचिपूर्ण तरीका है। इससे कोई फर्क नहीं पड़ता कि आपने अपने कोड को कितना बदल दिया है।
सुजय फड़के

@ JohnR.Strohm: VB.NET से C #: Doलूप में स्विच करने पर दूसरी सबसे अधिक सुविधा है । क्यूं कर? क्योंकि मैं एक लूप को बदल सकता हूं जिसे Doलूप और टाइप में गहरा ब्रेक चाहिए और Exit Doकोई नहीं GoTo। नेस्टेड लूप हर समय होता है। स्टैक को तोड़ना कुछ समय का होता है।
जोशुआ

7

हतोत्साहित करने वाले अधिकांश "धर्म" का निर्माण करते हैं जिसे भगवान जिक्स्ट्रा ने पैदा किया है जो 60 के दशक की शुरुआत में इसे अंधाधुंध करने के लिए मजबूर कर रहा था:

  • कोड के जो भी ब्लॉक में कहीं भी कूदो
    • फ़ंक्शन को भीख से निष्पादित नहीं किया गया है
    • लूप्स को शुरुआत से निष्पादित नहीं किया गया
    • चर आरंभीकरण छोड़ दिया
  • किसी भी संभव सफाई के बिना कोड के ब्लॉक से दूर कूदो।

gotoआधुनिक भाषाओं के कथन से इसका कोई लेना-देना नहीं है , जिसका अस्तित्व केवल उपलब्ध कराई गई भाषा के अलावा कोड संरचनाओं के निर्माण के समर्थन के कारण है।

विशेष रूप से ऊपर दिए गए पहले मुख्य बिंदु को अब अनुमति दी गई है और दूसरा साफ किया गया है (यदि आप gotoएक ब्लॉक से बाहर हैं तो स्टैक ठीक से खोल दिया गया है और सभी उचित विध्वंसक कहलाते हैं)

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

मैं उपयोग किए बिना एक संपूर्ण कार्यक्रम लिख सकता हूं if, बस for। बेशक, यह अच्छी तरह से पठनीय नहीं होगा, एक नज़र अनाड़ी और अनावश्यक रूप से जटिल।

लेकिन समस्या यह नहीं है for। यह मैं हूँ।

चीजों की तरह break, continue, throw, bool needed=true; while(needed) {...}, आदि की तुलना में अधिक ध्यान देने योग्य बात कर रहे हैं Masquerade goto Djikstrarian उग्रपंथियों की scimitars से दूर भागने की, कि -50 साल आधुनिक laguages- के आविष्कार के बाद अभी भी अपने कैदियों चाहते हैं। वे भूल गए कि जिक्स्ट्रा किस बारे में बात कर रहे थे, उन्हें केवल उनके नोट का शीर्षक याद है (GOTO हानिकारक माना जाता है, और यह उनका onw शीर्षक भी नहीं था: यह संपादक द्वारा बदल दिया गया था) और दोष, मार, मार और दोष उनके 4 दोष होने पर पत्र क्रम में रखा गया।

यह 2011 है: यह समझने का समय है कि जिनकोस्ट्रा के बारे में मजबूर किया गया था gotoउस GOTOबयान से निपटने के लिए ध्यान देने योग्य नहीं है ।


1
"ब्रेक, कंटिन्यू, थ्रो, बूल की जरूरत जैसी चीजें सच है; जबकि (जरूरत) {...}, इत्यादि, मस्कारा गोटो से ज्यादा ध्यान देने योग्य हैं" मैं इससे सहमत नहीं हूं। मैं पसंद करता हूं "ब्रेक जैसी चीजें प्रतिबंधित गोटो हैं", या ऐसा कुछ। गोटो के साथ मुख्य समस्या यह है कि यह आमतौर पर बहुत शक्तिशाली है। इस हद तक कि मौजूदा गोटो, दिज्क्स्ट्रा की तुलना में कम शक्तिशाली है, आपका जवाब मेरे साथ ठीक है।
मुहम्मद अलकरौरी

2
@ मुहम्मदअल्करौरी: मैं पूरी तरह सहमत हूं। आपको बस मेरी अवधारणा को व्यक्त करने के लिए एक बेहतर शब्दांकन मिला। मेरा कहना यह है कि उन प्रतिबंधों को कभी-कभी लागू नहीं किया जा सकता है और जिस तरह का प्रतिबंध आपको चाहिए वह भाषा में नहीं है। फिर एक अधिक "शक्तिशाली" चीज, कम विशेष, वह है जो आपको वर्कअराउंड करने में सक्षम बनाती है। उदाहरण के लिए, जावा break nC ++ में उपलब्ध नहीं है, इसलिए goto escape, भले ही escapen-ple लूप से बाहर होने की आवश्यकता न हो।
एमिलियो गारवगलिया

4

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

यदि (स्थानीय) गोटो काफी पठनीयता को नुकसान पहुंचा रहे हैं, तो यह आमतौर पर संकेत है कि गोटो वाला फ़ंक्शन बहुत जटिल हो गया है।

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


1
इसका उत्तर सबसे पुराने "लेट पोटेटो चिप्स" स्लोगन में कहा गया है: "बेटी तुम सिर्फ एक नहीं खा सकती"। आपके उदाहरण में, आपके पास दो "इंटरलॉकिंग" हैं (जो भी इसका मतलब है, और मैं शर्त लगा रहा हूं कि यह सुंदर नहीं है) लूप, और गोटो ने आपको एक सस्ता आउट दिया। रखरखाव आदमी के बारे में क्या, जो उस बस को हिट करने के बाद उस कोड को संशोधित करना है? क्या गोटो उसके जीवन को आसान या कठिन बनाने वाला है? क्या उन दो छोरों को पुनर्विचार की आवश्यकता है?
जॉन आर। स्ट्रॉ डेम

3

मुझे लगता है कि यह पूरा मुद्दा गलत पेड़ को काटने का मामला है।

GOTO जैसा कि मेरे लिए समस्याग्रस्त नहीं लगता है, बल्कि यह अक्सर एक वास्तविक पाप का एक लक्षण है: स्पेगेटी कोड।

यदि GOTO प्रवाह नियंत्रण लाइनों के प्रमुख क्रॉसिंग का कारण बनता है तो यह खराब है, अवधि। यदि यह बिना किसी प्रवाह नियंत्रण रेखा के पार करता है तो यह हानिरहित है। ग्रे ज़ोन में हमारे बीच में लूप बेलआउट जैसी चीजें होती हैं, फिर भी कुछ भाषाएं ऐसी हैं, जिन्होंने निर्माण को नहीं जोड़ा है जो सभी वैध ग्रे मामलों को कवर करती हैं।

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


जिस केस से आप सहमत हैं, उसे कभी-कभी "लूप एंड अ हाफ" या "एन प्लस वन हाफ लूप" कहा जाता है और यह s के लिए एक प्रसिद्ध उपयोग-केस है gotoजो लूप में कूदता है (यदि भाषा इसकी अनुमति देती है, तो दूसरे केस के बाद से; बीच में पाश से बाहर, आमतौर पर बिना तुच्छ है goto)।
कोनराड रुडोल्फ

(काश, ज्यादातर भाषाएं एक लूप में कूदने से मना करती हैं।)
कोनराड रूडोल्फ

@KonradRudolph: यदि आप GOTO के साथ "लूप" को लागू करते हैं तो इसमें कूदने के लिए कोई अन्य लूप संरचना नहीं है।
लोरेन Pechtel

1
मैं के बारे में सोच gotoचिल्ला के रूप में नियंत्रण प्रवाह यहाँ नहीं है फिट सामान्य संरचित-प्रोग्रामिंग पैटर्न । क्योंकि नियंत्रण प्रवाह जो संरचित प्रोग्रामिंग पैटर्न फिट करते हैं, उन कारणों की तुलना में आसान होते हैं, जो संभव नहीं होने पर ऐसे पैटर्न का उपयोग करने का प्रयास करना चाहिए; अगर कोड ऐसे पैटर्न में फिट बैठता है, तो किसी को चिल्लाना नहीं चाहिए कि यह नहीं है। दूसरी ओर, ऐसे मामलों में जहां कोड वास्तव में इस तरह के पैटर्न को फिट नहीं करता है, इसके बारे में चिल्लाना कोड फिट होने का नाटक करने से बेहतर हो सकता है जब यह वास्तव में नहीं होता है।
सुपरकैट

1

हां, डेवलपर के अनुभव के लाभ के लिए गोटो का उपयोग किया जा सकता है: http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/

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


1

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


0

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


3
हो सकता है, लेकिन आप किसी भी तर्क प्रदान नहीं किया है
Casebash

दिज्क्स्त्र ने तर्क दिया, विस्तार से, दशकों पहले।
जॉन आर। स्ट्रॉ डेम

2
बस हठधर्मिता। कोई प्रतिध्वनि नहीं। नोट: Djikstra कहीं भी वैध परिणाम नहीं है: यह 60 के दशक की शुरुआत में BASIC या FORTRAN GOTO के बयान की बात कर रहा था। आज के गोट्स-एस की वास्तव में एनीमिक (उन की शक्ति की तुलना में) से उनका कोई लेना-देना नहीं है।
एमिलियो गरवाग्लिया

0

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


-1

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


मेरा तर्क है कि जब भाषाओं में ये दोनों विशेषताएं होती हैं, gotoतो आमतौर पर उन भाषाओं से अनुपस्थित रहते हैं।
चिन्मय कांची

लेकिन ऐसा इसलिए है क्योंकि उन्हें उनकी ज़रूरत नहीं है, या क्योंकि लोग सोचते हैं कि उन्हें उनकी ज़रूरत नहीं है?
माइकल के

आपके विचार बड़े पैमाने पर हैं। कई मामले हैं जब gotoबहुत समस्या डोमेन शब्दार्थ के सबसे करीब है, और कुछ भी एक गंदा हैक होगा।
एसके-तर्क

@ एसके-तर्क: मुझे नहीं लगता कि शब्द "बिगोटेड" का मतलब है कि आप क्या सोचते हैं इसका मतलब है।
कीथ थॉम्पसन

1
@ कीथ, "असहिष्णु रूप से अपने स्वयं के विचारों और पूर्वाग्रहों के लिए समर्पित" - यही वह है जो मैं लगातार यहां देखता हूं, इस गोटे को आंखों पर पट्टी बांधने के साथ। " हमेशा प्रतिस्थापित किया जाना चाहिए " कट्टरपंथी शब्द हैं, कम से कम। एक उचित, ध्वनि राय के करीब कुछ भी नहीं है, लेकिन सिर्फ एक शुद्ध कट्टरता है। यह "हमेशा" किसी भी वैकल्पिक राय के लिए कोई जगह नहीं छोड़ता है, देखें?
एसके-तर्क 10
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.