थंक

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

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

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

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

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

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

निम्नलिखित जावास्क्रिप्ट (ES6) में एक सरल प्रदर्शन है:

वस्तु-उन्मुख प्रोग्रामिंग
थंक्स ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग  प्लेटफ़ॉर्म में उपयोगी होते हैं जो एक क्लास (कंप्यूटर प्रोग्रामिंग) को एकाधिक इनहेरिटेंस की अनुमति देते हैं, जिससे ऐसी स्थिति उत्पन्न होती है जहां एक ही विधि (कंप्यूटर प्रोग्रामिंग) को कई इंटरफेस में से किसी एक के माध्यम से बुलाया जा सकता है। निम्नलिखित कोड C++ में ऐसी स्थिति को दर्शाता है।

इस उदाहरण में, प्रत्येक वर्ग ए, बी और सी के लिए उत्पन्न कोड में एक प्रेषण तालिका शामिल होगी जिसका उपयोग कॉल करने के लिए किया जा सकता है Access उस प्रकार की किसी वस्तु पर, उसी प्रकार के संदर्भ के माध्यम से। क्लास सी में एक अतिरिक्त डिस्पैच टेबल होगी, जिसका उपयोग कॉल करने के लिए किया जाएगा Access प्रकार बी के संदर्भ के माध्यम से प्रकार सी की एक वस्तु पर अभिव्यक्ति b->Access बी की अपनी प्रेषण तालिका या अतिरिक्त सी तालिका का उपयोग करेगा, जो कि बी द्वारा संदर्भित ऑब्जेक्ट के प्रकार पर निर्भर करता है। यदि यह C प्रकार के ऑब्जेक्ट को संदर्भित करता है, तो कंपाइलर को यह सुनिश्चित करना होगा कि C Access कार्यान्वयन उस ऑब्जेक्ट के विरासत वाले बी भाग के बजाय संपूर्ण सी ऑब्जेक्ट के लिए यह (कंप्यूटर प्रोग्रामिंग) प्राप्त करता है। इस सूचक समायोजन समस्या के प्रत्यक्ष दृष्टिकोण के रूप में, कंपाइलर प्रत्येक प्रेषण तालिका प्रविष्टि में एक पूर्णांक ऑफसेट शामिल कर सकता है। यह ऑफसेट संदर्भ के पते और विधि कार्यान्वयन के लिए आवश्यक पते के बीच का अंतर है। इन प्रेषण तालिकाओं के माध्यम से प्रत्येक कॉल के लिए उत्पन्न कोड को ऑफसेट पुनर्प्राप्त करना होगा और विधि को कॉल करने से पहले इंस्टेंस पते को समायोजित करने के लिए इसका उपयोग करना होगा।

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

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

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

इंटरऑपरेबिलिटी थंक्स पर अधिकांश साहित्य MS-DOS, OS/2 सहित विभिन्न विंटेल प्लेटफार्मों से संबंधित है। माइक्रोसॉफ़्ट विंडोज़ ़    और .NET Framework|.NET, और 16-बिट से 32-बिट मेमोरी एड्रेसिंग में संक्रमण। चूँकि ग्राहक एक प्लेटफ़ॉर्म से दूसरे प्लेटफ़ॉर्म पर स्थानांतरित हो गए हैं, पुराने प्लेटफ़ॉर्म के लिए लिखे गए विरासत सॉफ्टवेयर का समर्थन करने के लिए थंक्स आवश्यक हो गए हैं।

x86 पर 32-बिट से 64-बिट कोड में परिवर्तन भी थंकिंग (WoW64) के एक रूप का उपयोग करता है। हालाँकि, क्योंकि x86-64 पता स्थान 32-बिट कोड के लिए उपलब्ध स्थान से बड़ा है, पुराने जेनेरिक थंक तंत्र का उपयोग 32-बिट कोड से 64-बिट कोड को कॉल करने के लिए नहीं किया जा सकता है। रेफरी> 32-बिट कोड को 64-बिट कोड कॉल करने का एकमात्र मामला WoW64 द्वारा विंडोज एपीआई को 32-बिट में बदलना है।

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

थंक टेक्नोलॉजीज

 * डॉस संरक्षित मोड इंटरफ़ेस (DPMI)
 * डॉस संरक्षित मोड सेवाएँ (DPMS)
 * जे/डायरेक्ट
 * यूनिकोड के लिए माइक्रोसॉफ्ट लेयर
 * प्लेटफ़ॉर्म मंगलाचरण सेवाएँ
 * Win32s
 * विंडोज़ पर विंडोज़
 * वाह64
 * libffi

संबंधित अवधारणाएँ

 * अनाम फ़ंक्शन
 * वायदा और वादे
 * सुदूर प्रणाली संदेश
 * शिम (कंप्यूटिंग)
 * ट्रैम्पोलिन (कंप्यूटिंग)
 * कम करने योग्य अभिव्यक्ति