वापसी विवरण

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

सिंहावलोकन

C (प्रोग्रामिंग भाषा) और C++ में, return exp; (कहाँ exp एक अभिव्यक्ति (प्रोग्रामिंग) है) एक वक्तव्य (प्रोग्रामिंग) है जो एक फ़ंक्शन को कॉलिंग फ़ंक्शन पर प्रोग्राम के निष्पादन को वापस करने के लिए कहता है, और के मूल्य की रिपोर्ट करता है exp. यदि किसी फ़ंक्शन में रिटर्न प्रकार Void प्रकार है, तो रिटर्न स्टेटमेंट का उपयोग किसी मान के बिना किया जा सकता है, ऐसी स्थिति में प्रोग्राम केवल वर्तमान फ़ंक्शन से बाहर हो जाता है और कॉलिंग फ़ंक्शन पर वापस आ जाता है।

पास्कल (प्रोग्रामिंग भाषा) में कोई रिटर्न स्टेटमेंट नहीं है। (हालाँकि, नए पास्कल में, Exit(exp); किसी मान को तुरंत वापस करने के लिए उपयोग किया जा सकता है। मापदंडों के बिना, यह बस प्रक्रिया को तोड़ देता है।) जब निष्पादन अपने अंतिम निष्पादन योग्य कथन पर पहुंचता है तो एक सबरूटीन स्वचालित रूप से वापस आ जाता है। मानों को एक ऐसे पहचानकर्ता को निर्दिष्ट करके वापस किया जा सकता है जिसका नाम सबरूटीन, पास्कल शब्दावली में एक फ़ंक्शन, के समान है। इस प्रकार फ़ंक्शन पहचानकर्ता का उपयोग पुनरावर्ती कॉल के लिए और परिणाम धारक के रूप में किया जाता है; यह वाक्यात्मक रूप से एक स्पष्ट आउटपुट पैरामीटर के समान है। [[फोरट्रान द्वितीय]] और फोरट्रान 77 में समान सिंटैक्स का उपयोग किया जाता है, हालांकि फोरट्रान II में एक रिटर्न स्टेटमेंट जोड़ा गया था। कुछ अन्य भाषाओं में फ़ंक्शन पहचानकर्ता के बजाय उपयोगकर्ता परिभाषित परिणाम चर का उपयोग किया जाता है।

ओबेरोन-07 (प्रोग्रामिंग भाषा) (ओबेरॉन-07) में रिटर्न स्टेटमेंट के बजाय रिटर्न क्लॉज है। रिटर्न क्लॉज प्रक्रिया निकाय के अंतिम विवरण के बाद रखा जाता है। यह प्रक्रिया से उचित रिटर्न और रिटर्न मान की संकलन-समय जांच करने में सक्षम बनाता है।

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

अन्य मामलों में यदि कोई स्पष्ट रिटर्न स्टेटमेंट नहीं है तो एक शून्य मान लौटाया जाता है: पायथन (प्रोग्रामिंग भाषा) में, मान None रिटर्न स्टेटमेंट छोड़े जाने पर लौटाया जाता है, जबकि जावास्क्रिप्ट में मान undefined लौटा दिया जाता है.

विंडोज़ पॉवरशेल में सभी मूल्यांकित अभिव्यक्तियाँ जिन्हें कैप्चर नहीं किया गया है (उदाहरण के लिए, एक वेरिएबल को असाइन किया गया है, शून्य प्रकार या पाइपलाइन (यूनिक्स) से /dev/null|$null में रूपांतरण) को सबरूटीन से एक सरणी में तत्वों के रूप में, या के रूप में लौटाया जाता है ऐसे मामले में जब केवल एक ही वस्तु को कैप्चर नहीं किया गया हो।

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

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

वाक्यविन्यास

रिटर्न स्टेटमेंट कई आकार में आते हैं। निम्नलिखित वाक्यविन्यास सबसे आम हैं:

Language	Return statement	If value omitted, return
Ada, Bourne shell,^[1] C, C++, Java, PHP, C#, JavaScript, D	return value;	In the Bourne shell, exit value of the last command executed in the function In C^[2] and C++,^[3] undefined behavior if function is value-returning In PHP,^[4] returns `NULL` In Javascript,^[5] returns the value `undefined` In Java and C#, not permitted if function is value-returning
BASIC	RETURN
Lisp	(return value)	Last statement value
Perl, Ruby	return @values; return $value; return; or a contextual return sequence	Last statement value
PL/I	return(expression); return;	Undefined behavior if procedure is declared as returning a value
Python	return value	`None`
Smalltalk	^ value
Tcl	return return $value return -code error "Error message" or some more complicated combination of options	Last statement value
Visual Basic .NET	Return value
Windows PowerShell	return value;	Object
x86 assembly	ret	Contents of eax register (by conventions)

कुछ असेंबली भाषाओं में, उदाहरण के लिए एमओएस टेक्नोलॉजी 6502 के लिए, निमोनिक आरटीएस (सबरूटीन से रीटर्न) का उपयोग किया जाता है।

एकाधिक रिटर्न स्टेटमेंट

स्पष्ट रिटर्न स्टेटमेंट वाली भाषाएँ एक ही फ़ंक्शन में एकाधिक रिटर्न स्टेटमेंट की संभावना पैदा करती हैं। यह अच्छी बात है या नहीं यह विवादास्पद है।

संरचित प्रोग्रामिंग के मजबूत अनुयायी यह सुनिश्चित करते हैं कि प्रत्येक फ़ंक्शन में एक एकल प्रविष्टि और एक एकल निकास (एसईएसई) हो। इस प्रकार यह तर्क दिया गया है^[6] किसी को सबरूटीन के पाठ्य अंत को छोड़कर स्पष्ट रिटर्न स्टेटमेंट के उपयोग से बचना चाहिए, यह देखते हुए कि, जब इसका उपयोग जल्दी लौटने के लिए किया जाता है, तो यह उसी प्रकार की समस्याओं से ग्रस्त हो सकता है जो GOTO स्टेटमेंट के लिए उत्पन्न होती हैं। इसके विपरीत, यह तर्क दिया जा सकता है कि रिटर्न स्टेटमेंट का उपयोग तब सार्थक होता है जब विकल्प अधिक जटिल कोड होता है, जैसे गहरा घोंसला बनाना, पठनीयता को नुकसान पहुंचाना।

अपनी 2004 की पाठ्यपुस्तक में, डेविड वॉट (कंप्यूटर वैज्ञानिक) लिखते हैं कि एकल-प्रवेश बहु-निकास नियंत्रण प्रवाह अक्सर वांछनीय होते हैं। एस-अल्गोल की टेनेंट की रूपरेखा धारणा का उपयोग करते हुए, वाट समसामयिक प्रोग्रामिंग भाषाओं में पाए जाने वाले नियंत्रण प्रवाह निर्माणों का समान रूप से वर्णन करता है और यह समझाने का प्रयास करता है कि बहु-निकास नियंत्रण प्रवाह के संदर्भ में कुछ प्रकार के सीक्वेंसर दूसरों के लिए बेहतर क्यों हैं। वॉट लिखते हैं कि अप्रतिबंधित के लिए जाओ (जंप सीक्वेंसर) खराब हैं क्योंकि जंप का गंतव्य किसी प्रोग्राम के पाठक के लिए स्व-व्याख्यात्मक नहीं होता है जब तक कि पाठक उस वास्तविक लेबल या पते को ढूंढ और जांच नहीं करता है जो जंप का लक्ष्य है। इसके विपरीत, वॉट का तर्क है कि रिटर्न सीक्वेंसर का वैचारिक इरादा अपने गंतव्य की जांच किए बिना, अपने स्वयं के संदर्भ से स्पष्ट है। इसके अलावा, वॉट लिखते हैं कि सीक्वेंसर के एक वर्ग को एस्केप सीक्वेंसर के रूप में जाना जाता है, जिसे सीक्वेंसर के रूप में परिभाषित किया गया है जो पाठ्य रूप से संलग्न कमांड या प्रक्रिया के निष्पादन को समाप्त करता है, इसमें लूप से तोड़ो बयान (बहु-स्तरीय ब्रेक सहित) और रिटर्न स्टेटमेंट दोनों शामिल हैं। वाट यह भी नोट करते हैं कि जबकि जंप सीक्वेंसर (गोटो) को सी जैसी भाषाओं में कुछ हद तक प्रतिबंधित किया गया है, जहां लक्ष्य स्थानीय ब्लॉक के अंदर या एक बाहरी ब्लॉक को घेरना चाहिए, वह प्रतिबंध अकेले सी में गोटो के इरादे को पूरा करने के लिए पर्याप्त नहीं है। -वर्णन और इसलिए वे अभी भी स्पेगेटी कोड का उत्पादन कर सकते हैं। वाट यह भी जांचता है कि अपवाद सीक्वेंसर एस्केप और जंप सीक्वेंसर से कैसे भिन्न हैं; इस पर विवरण के लिए संरचित प्रोग्रामिंग पर लेख देखें।^[7] एरिक एस. रॉबर्ट्स द्वारा उद्धृत अनुभवजन्य अध्ययनों के अनुसार, छात्र प्रोग्रामरों को पास्कल जैसी भाषा में कई सरल समस्याओं के लिए सही समाधान तैयार करने में कठिनाई हुई, जो कई निकास बिंदुओं की अनुमति नहीं देती है। किसी सरणी में किसी तत्व को रैखिक रूप से खोजने के लिए फ़ंक्शन लिखने की समस्या के लिए, हेनरी शापिरो (रॉबर्ट्स द्वारा उद्धृत) द्वारा 1980 के एक अध्ययन में पाया गया कि केवल पास्कल द्वारा प्रदान की गई नियंत्रण संरचनाओं का उपयोग करके, केवल 20% विषयों द्वारा सही समाधान दिया गया था। , जबकि किसी भी विषय ने इस समस्या के लिए गलत कोड नहीं लिखा, यदि उसे लूप के बीच से रिटर्न लिखने की अनुमति दी गई हो।^[8] केंट बेक और मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर) सहित अन्य लोगों का तर्क है कि एक या अधिक गार्ड (कंप्यूटर विज्ञान) - फ़ंक्शन की शुरुआत के निकट सशर्त प्रारंभिक निकास रिटर्न स्टेटमेंट - अक्सर विकल्प की तुलना में फ़ंक्शन को पढ़ना आसान बनाते हैं।^[9]^[10]^[11]^[12] शीघ्र निकास में सबसे आम समस्या यह है कि क्लीनअप या अंतिम विवरण निष्पादित नहीं किए जाते हैं - उदाहरण के लिए, आवंटित मेमोरी को आवंटित नहीं किया जाता है, या खुली फ़ाइलें बंद नहीं की जाती हैं, जिससे रिसाव होता है। इन्हें प्रत्येक रिटर्न साइट पर किया जाना चाहिए, जो भंगुर है और आसानी से बग पैदा कर सकता है। उदाहरण के लिए, बाद के विकास में, डेवलपर द्वारा रिटर्न स्टेटमेंट को नजरअंदाज किया जा सकता है, और एक क्रिया जो सबरूटीन के अंत में की जानी चाहिए (उदाहरण के लिए एक ट्रेसिंग (सॉफ़्टवेयर) स्टेटमेंट) सभी मामलों में नहीं की जा सकती है। बिना रिटर्न स्टेटमेंट वाली भाषाओं, जैसे मानक पास्कल में यह समस्या नहीं है। कुछ भाषाएँ, जैसे C++ और Python, ऐसी अवधारणाओं का उपयोग करती हैं जो रिटर्न (या अपवाद थ्रो) पर कार्यों को स्वचालित रूप से निष्पादित करने की अनुमति देती हैं जो इनमें से कुछ मुद्दों को कम करती हैं - इन्हें अक्सर प्रयास/अंततः या समान के रूप में जाना जाता है। इन अंतिम खंडों जैसी कार्यक्षमता को गोटो द्वारा सबरूटीन के एकल रिटर्न बिंदु पर कार्यान्वित किया जा सकता है। एक वैकल्पिक समाधान संसाधनों को आवंटित करने के लिए फ़ंक्शन निकास पर सामान्य स्टैक अनवाइंडिंग (वेरिएबल डीलोकेशन) का उपयोग करना है, जैसे कि स्थानीय चर पर विनाशकों के माध्यम से, या पायथन के स्टेटमेंट जैसे समान तंत्र के माध्यम से।

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

जावा (प्रोग्रामिंग भाषा) में - और इसके बाद तैयार की गई समान भाषाएं, जैसे जावास्क्रिप्ट - रिटर्न स्टेटमेंट के बाद भी कोड निष्पादित करना संभव है, क्योंकि ट्राई-कैच ब्लॉक|ट्राई-कैच संरचना का अंतिम ब्लॉक हमेशा निष्पादित होता है। इसलिए यदि रिटर्न स्टेटमेंट को ट्राई या कैच ब्लॉक के भीतर कहीं रखा गया है तो कोड अंततः (यदि जोड़ा गया है) निष्पादित किया जाएगा। किसी गैर-आदिम प्रकार (पहले से ही लौटाई गई वस्तु की एक संपत्ति) के रिटर्न मान को बदलना भी संभव है क्योंकि निकास बाद में भी होता है।^[13]

उपज विवरण

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

कॉल/वापसी क्रम

हार्डवेयर निर्देश सेट के आधार पर कई संभावित कॉल/रिटर्न अनुक्रम संभव हैं, जिनमें निम्नलिखित शामिल हैं:

CALL e> निर्देश स्टैक और शाखाओं पर अगले निर्देश के पते को निर्दिष्ट पते पर धकेलता है। RETURN ई> निर्देश स्टैक से रिटर्न एड्रेस को इंस्ट्रक्शन पॉइंटर में पॉप करता है और उस पते पर निष्पादन फिर से शुरू होता है। (उदाहरण: x86, पीडीपी-11)
CALL ई> निर्देश एक रजिस्टर में अगले निर्देश का पता रखता है और निर्दिष्ट पते पर शाखाएं डालता है। RETURN ई> निर्देश अनुक्रम रजिस्टर से रिटर्न पते को निर्देश सूचक में रखता है और उस पते पर निष्पादन फिर से शुरू होता है। (उदाहरण: आईबीएम सिस्टम/360 और ज़ेड/आर्किटेक्चर के माध्यम से उत्तराधिकारी, सबसे कम निर्देश सेट कंप्यूटिंग आर्किटेक्चर)
CALL ई> निर्देश कॉल पते पर भंडारण स्थान में अगला (या वर्तमान) निर्देश का पता रखता है और निर्दिष्ट पते+1 पर शाखाएं देता है। RETURN ई> अनुदेश अनुक्रम शाखाओं को अप्रत्यक्ष रूप से सबरूटीन के पहले निर्देश पर कूदकर वापसी पते पर भेजता है। (उदाहरण: आईबीएम 1130, एसडीएस 9 सीरीज, पीडीपी-8)

यह भी देखें

वापसी प्रकार
बाहर निकलने की स्थिति

संदर्भ

↑ in the Bourne shell, only integers in the range 0-255 may be returned: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#return
↑ https://msdn.microsoft.com/en-us/library/sta56yeb.aspx MSDN: return Statement (C)
↑ "MSDN: return Statement (C++)". MSDN.
↑ "PHP: return - Manual". PHP Manual. The PHP Group. Retrieved 26 March 2013.
↑ "Return - Javascript". MDN Javascript Reference. Mozilla Developer Network. Retrieved 27 March 2013.
↑ C++ Notes: Function return Statement
↑ Watt, David Anthony; Findlay, William (2004). प्रोग्रामिंग भाषा डिज़ाइन अवधारणाएँ. John Wiley & Sons. pp. 215–221. ISBN 978-0-470-85320-7.
↑ Roberts, E. (1995). "Loop Exits and Structured Programming: Reopening the Debate". ACM SIGCSE Bulletin. 27 (1): 268–272.
↑ Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts. "Refactoring: Improving the Design of Existing Code (Google eBook)". section "Replace Nested Conditional with Guard Clauses". 2012. p. 237, p. 250. quote: "... one exit point mentality ... I don't follow the rule about one exit point from a method."
↑ Kent Beck. "Implementation Patterns". 2007. "Chapter 7: Behavior", section "Guard Clause".
↑ "Multiple return statements"
↑ Fred Swartz. "Return statements and the single exit fantasy".
↑ The finally Block,The Java Tutorials

[1] the Bourne shell, only integers in the range 0-255 may be returned: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#return

[2] ttps://msdn.microsoft.com/en-us/library/sta56yeb.aspx MSDN: return Statement (C)

[3] "MSDN: return Statement (C++)". MSDN.

[4] "PHP: return - Manual". PHP Manual. The PHP Group. Retrieved 26 March 2013.

[5] "Return - Javascript". MDN Javascript Reference. Mozilla Developer Network. Retrieved 27 March 2013.

[6] C++ Notes: Function return Statement

[7] Watt, David Anthony; Findlay, William (2004). प्रोग्रामिंग भाषा डिज़ाइन अवधारणाएँ. John Wiley & Sons. pp. 215–221. ISBN 978-0-470-85320-7.

[8] Roberts, E. (1995). "Loop Exits and Structured Programming: Reopening the Debate". ACM SIGCSE Bulletin. 27 (1): 268–272.

[9] Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts. "Refactoring: Improving the Design of Existing Code (Google eBook)". section "Replace Nested Conditional with Guard Clauses". 2012. p. 237, p. 250. quote: "... one exit point mentality ... I don't follow the rule about one exit point from a method."

[10] Kent Beck. "Implementation Patterns". 2007. "Chapter 7: Behavior", section "Guard Clause".

[11] "Multiple return statements"

[12] Fred Swartz. "Return statements and the single exit fantasy".

[13] The finally Block,The Java Tutorials

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]