थंक: Difference between revisions
(Created page with "{{otheruses}}{{wiktionary}} {{short description|Computing term}} {{use dmy dates|date=January 2020|cs1-dates=y}} कंप्यूटर प्रोग्रामिं...") |
No edit summary |
||
| Line 2: | Line 2: | ||
{{short description|Computing term}} | {{short description|Computing term}} | ||
{{use dmy dates|date=January 2020|cs1-dates=y}} | {{use dmy dates|date=January 2020|cs1-dates=y}} | ||
यह शब्द ''सोचो'' क्रिया के सनकी अंग्रेजी अनियमित क्रिया रूप के रूप में उत्पन्न हुआ। यह [[ALGOL 60]] कंपाइलरों में थंक्स के मूल उपयोग को संदर्भित करता है, जिसे यह निर्धारित करने के लिए विशेष विश्लेषण (विचार) की आवश्यकता होती है कि किस प्रकार की दिनचर्या उत्पन्न की जाए।<ref> | [[कंप्यूटर प्रोग्रामिंग]] में, थंक एक [[सबरूटीन]] है जिसका उपयोग किसी गणना को दूसरे सबरूटीन में इंजेक्ट करने के लिए किया जाता है। थंक्स का उपयोग मुख्य रूप से किसी गणना में देरी करने के लिए किया जाता है जब तक कि उसके परिणाम की आवश्यकता न हो, या अन्य सबरूटीन की आरम्भ या अंत में संचालन सम्मिलित करने के लिए किया जाता है। उनके पास [[कोड जनरेशन (कंपाइलर)]] और [[मॉड्यूलर प्रोग्रामिंग]] में कई अन्य अनुप्रयोग हैं। | ||
यह शब्द ''सोचो'' क्रिया के सनकी अंग्रेजी अनियमित क्रिया रूप के रूप में उत्पन्न हुआ। यह [[ALGOL 60|एल्गोल 60]] कंपाइलरों में थंक्स के मूल उपयोग को संदर्भित करता है, जिसे यह निर्धारित करने के लिए विशेष विश्लेषण (विचार) की आवश्यकता होती है कि किस प्रकार की दिनचर्या उत्पन्न की जाए।<ref> | |||
Eric Raymond rejects "a couple of onomatopoeic myths circulating about the origin of this term" and cites the inventors of the thunk recalling that the term "was coined after they realized (in the wee hours after hours of discussion) that the type of an argument in Algol-60 could be figured out in advance with a little compile-time thought [...] In other words, it had 'already been thought of'; thus it was christened a ''thunk'', which is 'the past tense of "think" at two in the morning'. See: {{cite book | Eric Raymond rejects "a couple of onomatopoeic myths circulating about the origin of this term" and cites the inventors of the thunk recalling that the term "was coined after they realized (in the wee hours after hours of discussion) that the type of an argument in Algol-60 could be figured out in advance with a little compile-time thought [...] In other words, it had 'already been thought of'; thus it was christened a ''thunk'', which is 'the past tense of "think" at two in the morning'. See: {{cite book | ||
| last1 = Raymond | | last1 = Raymond | ||
| Line 21: | Line 22: | ||
}} | }} | ||
</ref><ref>See Ingerman (1961): "The translator knows what kind of thunk to create by considering the formation of the actual parameter and the previously scanned declarations.… [W]hen a procedure declaration is being compiled, the translator, again by observing syntax, knows what kind of address to expect from a thunk."</ref> | </ref><ref>See Ingerman (1961): "The translator knows what kind of thunk to create by considering the formation of the actual parameter and the previously scanned declarations.… [W]hen a procedure declaration is being compiled, the translator, again by observing syntax, knows what kind of address to expect from a thunk."</ref> | ||
==पृष्ठभूमि== | ==पृष्ठभूमि== | ||
[[संकलक]] अनुसंधान के प्रारंभिक वर्षों में विभिन्न [[मूल्यांकन रणनीति]] के साथ व्यापक प्रयोग देखा गया। एक महत्वपूर्ण प्रश्न यह था कि यदि तर्क स्थिरांक के बजाय मनमाने ढंग से गणितीय अभिव्यक्ति हो सकते हैं तो सबरूटीन कॉल को कैसे संकलित किया जाए। एक दृष्टिकोण, जिसे [[मूल्य के आधार पर कॉल करें]] के रूप में जाना जाता है, कॉल से पहले सभी तर्कों की गणना करता है और फिर परिणामी मानों को सबरूटीन में भेजता है। प्रतिद्वंद्वी [[नाम से बुलाओ]] दृष्टिकोण में, सबरूटीन को अमूल्यांकित तर्क अभिव्यक्ति प्राप्त होती है और उसे इसका मूल्यांकन करना चाहिए। | [[संकलक]] अनुसंधान के प्रारंभिक वर्षों में विभिन्न [[मूल्यांकन रणनीति]] के साथ व्यापक प्रयोग देखा गया। एक महत्वपूर्ण प्रश्न यह था कि यदि तर्क स्थिरांक के बजाय मनमाने ढंग से गणितीय अभिव्यक्ति हो सकते हैं तो सबरूटीन कॉल को कैसे संकलित किया जाए। एक दृष्टिकोण, जिसे [[मूल्य के आधार पर कॉल करें]] के रूप में जाना जाता है, कॉल से पहले सभी तर्कों की गणना करता है और फिर परिणामी मानों को सबरूटीन में भेजता है। प्रतिद्वंद्वी [[नाम से बुलाओ]] दृष्टिकोण में, सबरूटीन को अमूल्यांकित तर्क अभिव्यक्ति प्राप्त होती है और उसे इसका मूल्यांकन करना चाहिए। | ||
| Line 40: | Line 39: | ||
|doi-access = free | |doi-access = free | ||
}} | }} | ||
</ref>}} इस सहायक सबरूटीन को फिर मूल तर्क के स्थान पर मूल सबरूटीन में भेज दिया जाता है, जहां इसे आवश्यकतानुसार कई बार बुलाया जा सकता है। पीटर इंगरमैन ने सबसे पहले | </ref>}} इस सहायक सबरूटीन को फिर मूल तर्क के स्थान पर मूल सबरूटीन में भेज दिया जाता है, जहां इसे आवश्यकतानुसार कई बार बुलाया जा सकता है। पीटर इंगरमैन ने सबसे पहले एल्गोल 60 प्रोग्रामिंग भाषा के संदर्भ में थंक्स का वर्णन किया, जो कॉल-बाय-नाम मूल्यांकन का समर्थन करता है।<ref>{{cite journal | last=Ingerman | first=P. Z. | title=Thunks: a way of compiling procedure statements with some comments on procedure declarations | journal=Communications of the ACM | publisher=Association for Computing Machinery (ACM) | volume=4 | issue=1 | date=1961-01-01 | issn=0001-0782 | doi=10.1145/366062.366084 | pages=55–58 | s2cid=14646332 | doi-access=free }}</ref> | ||
==अनुप्रयोग== | ==अनुप्रयोग== | ||
===कार्यात्मक प्रोग्रामिंग=== | ===कार्यात्मक प्रोग्रामिंग=== | ||
यदपि सॉफ्टवेयर उद्योग बड़े पैमाने पर कॉल-बाय-वैल्यू और [[संदर्भ द्वारा कॉल करें]],कॉल-बाय-रेफरेंस मूल्यांकन पर मानकीकृत है,<ref>{{cite book|last=Scott|first=Michael|title=प्रोग्रामिंग भाषा व्यावहारिकता|year=2009|page=395}}</ref> [[कार्यात्मक प्रोग्रामिंग]] समुदाय में कॉल-बाय-नाम का सक्रिय अध्ययन प्रभावशील रहा। इस शोध ने [[आलसी मूल्यांकन]] प्रोग्रामिंग भाषाओं की एक श्रृंखला तैयार की जिसमें कॉल-बाय-नाम का कुछ प्रकार मानक मूल्यांकन रणनीति है। इन भाषाओं के लिए कंपाइलर, जैसे कि [[ग्लासगो हास्केल कंपाइलर]], ने थंक्स पर बहुत अधिक भरोसा किया है, इसमें अतिरिक्त सुविधा यह है कि थंक्स अपने प्रारंभिक परिणाम को सहेजते हैं ताकि वे इसे पुनर्गणना करने से बच सकें;<ref>{{cite book|first=Simon|last=Marlow|title=हास्केल में समानांतर और समवर्ती प्रोग्रामिंग|year=2013|page=10}}</ref> इसे [[संस्मरण]] या मूल्यांकन रणनीति कॉल बाय नीड के रूप में जाना जाता है। | |||
कार्यात्मक प्रोग्रामिंग भाषाओं ने प्रोग्रामर को स्पष्ट रूप से थंक्स उत्पन्न करने की भी अनुमति दी है। यह स्रोत कोड में एक अज्ञात | कार्यात्मक प्रोग्रामिंग भाषाओं ने प्रोग्रामर को स्पष्ट रूप से थंक्स उत्पन्न करने की भी अनुमति दी है। यह स्रोत कोड में एक अज्ञात कार्य में एक तर्क अभिव्यक्ति को लपेटकर किया जाता है जिसका अपना कोई पैरामीटर नहीं होता है। यह अभिव्यक्ति को तब तक मूल्यांकन करने से रोकता है जब तक कि प्राप्तकर्ता कार्य अज्ञात कार्य को कॉल नहीं करता है, जिससे कॉल-बाय-नाम के समान प्रभाव प्राप्त होता है।<ref>{{cite book|first=Christian|last=Queinnec|title=छोटे टुकड़ों में लिस्प|year=2003|page=176}}</ref> अन्य प्रोग्रामिंग भाषाओं में अनाम कार्यों को अपनाने से यह क्षमता व्यापक रूप से उपलब्ध हो गई है। | ||
निम्नलिखित जावास्क्रिप्ट ( | निम्नलिखित जावास्क्रिप्ट (ईएस6) में एक सरल प्रदर्शन है: | ||
<syntaxhighlight lang="js"> | <syntaxhighlight lang="js"> | ||
// 'hypot' is a binary function | // 'hypot' is a binary function | ||
| Line 68: | Line 65: | ||
===वस्तु-उन्मुख प्रोग्रामिंग=== | ===वस्तु-उन्मुख प्रोग्रामिंग=== | ||
थंक्स [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] प्लेटफ़ॉर्म में उपयोगी होते हैं जो एक [[क्लास (कंप्यूटर प्रोग्रामिंग)]] को एकाधिक इनहेरिटेंस की अनुमति देते हैं, जिससे ऐसी स्थिति उत्पन्न होती है जहां एक ही [[विधि (कंप्यूटर प्रोग्रामिंग)]] को कई इंटरफेस में से किसी एक के माध्यम से बुलाया जा सकता है। निम्नलिखित कोड [[C++]] में ऐसी स्थिति को दर्शाता है। | थंक्स [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] प्लेटफ़ॉर्म में उपयोगी होते हैं जो एक [[क्लास (कंप्यूटर प्रोग्रामिंग)]] को एकाधिक इनहेरिटेंस की अनुमति देते हैं, जिससे ऐसी स्थिति उत्पन्न होती है जहां एक ही [[विधि (कंप्यूटर प्रोग्रामिंग)]] को कई इंटरफेस में से किसी एक के माध्यम से बुलाया जा सकता है। निम्नलिखित कोड [[C++|सी++]] में ऐसी स्थिति को दर्शाता है। | ||
<syntaxhighlight lang="cpp"> | <syntaxhighlight lang="cpp"> | ||
| Line 105: | Line 102: | ||
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
इस उदाहरण में, प्रत्येक वर्ग ए, बी और सी के लिए उत्पन्न कोड में एक [[प्रेषण तालिका]] | इस उदाहरण में, प्रत्येक वर्ग ए, बी और सी के लिए उत्पन्न कोड में एक [[प्रेषण तालिका]] सम्मिलित होगी जिसका उपयोग कॉल करने के लिए किया जा सकता है {{code|Access}} उस प्रकार की किसी वस्तु पर, उसी प्रकार के संदर्भ के माध्यम से। क्लास सी में एक अतिरिक्त डिस्पैच टेबल होगी, जिसका उपयोग कॉल करने के लिए किया जाएगा {{code|Access}} प्रकार बी के संदर्भ के माध्यम से प्रकार सी की एक वस्तु पर अभिव्यक्ति {{code|b->Access()}} बी की अपनी प्रेषण तालिका या अतिरिक्त सी तालिका का उपयोग करेगा, जो कि बी द्वारा संदर्भित ऑब्जेक्ट के प्रकार पर निर्भर करता है। यदि यह C प्रकार के ऑब्जेक्ट को संदर्भित करता है, तो कंपाइलर को यह सुनिश्चित करना होगा कि C {{code|Access}} कार्यान्वयन उस ऑब्जेक्ट के विरासत वाले बी भाग के बजाय संपूर्ण सी ऑब्जेक्ट के लिए [[यह (कंप्यूटर प्रोग्रामिंग)]] प्राप्त करता है।<ref name=BS99>{{cite journal | ||
|last1 = Stroustrup | |last1 = Stroustrup | ||
|first1 = Bjarne | |first1 = Bjarne | ||
| Line 117: | Line 114: | ||
|access-date = 4 August 2014 | |access-date = 4 August 2014 | ||
}}</ref> | }}</ref> | ||
इस सूचक समायोजन समस्या के प्रत्यक्ष दृष्टिकोण के रूप में, कंपाइलर प्रत्येक प्रेषण तालिका प्रविष्टि में एक पूर्णांक ऑफसेट | |||
इस सूचक समायोजन समस्या के प्रत्यक्ष दृष्टिकोण के रूप में, कंपाइलर प्रत्येक प्रेषण तालिका प्रविष्टि में एक पूर्णांक ऑफसेट सम्मिलित कर सकता है। यह ऑफसेट संदर्भ के पते और विधि कार्यान्वयन के लिए आवश्यक पते के बीच का अंतर है। इन प्रेषण तालिकाओं के माध्यम से प्रत्येक कॉल के लिए उत्पन्न कोड को ऑफसेट पुनर्प्राप्त करना होगा और विधि को कॉल करने से पहले इंस्टेंस पते को समायोजित करने के लिए इसका उपयोग करना होगा। | |||
अभी वर्णित समाधान में पहले वर्णित कॉल-बाय-नाम के सरल कार्यान्वयन के समान समस्याएं हैं: कंपाइलर एक तर्क (उदाहरण पता) की गणना करने के लिए कोड की कई प्रतियां उत्पन्न करता है, जबकि ऑफसेट को पकड़ने के लिए प्रेषण तालिका आकार भी बढ़ाता है। एक विकल्प के रूप में, कंपाइलर सी के कार्यान्वयन के साथ एक समायोजक थंक उत्पन्न कर सकता है {{code|Access}} जो इंस्टेंस एड्रेस को आवश्यक मात्रा से समायोजित करता है और फिर विधि को कॉल करता है। थंक बी के लिए सी की प्रेषण तालिका में दिखाई दे सकता है, जिससे कॉल करने वालों को पते को स्वयं समायोजित करने की आवश्यकता समाप्त हो जाती है।<ref name=DH01>{{cite conference | अभी वर्णित समाधान में पहले वर्णित कॉल-बाय-नाम के सरल कार्यान्वयन के समान समस्याएं हैं: कंपाइलर एक तर्क (उदाहरण पता) की गणना करने के लिए कोड की कई प्रतियां उत्पन्न करता है, जबकि ऑफसेट को पकड़ने के लिए प्रेषण तालिका आकार भी बढ़ाता है। एक विकल्प के रूप में, कंपाइलर सी के कार्यान्वयन के साथ एक समायोजक थंक उत्पन्न कर सकता है {{code|Access}} जो इंस्टेंस एड्रेस को आवश्यक मात्रा से समायोजित करता है और फिर विधि को कॉल करता है। थंक बी के लिए सी की प्रेषण तालिका में दिखाई दे सकता है, जिससे कॉल करने वालों को पते को स्वयं समायोजित करने की आवश्यकता समाप्त हो जाती है।<ref name=DH01>{{cite conference | ||
| Line 133: | Line 131: | ||
|access-date = 24 February 2011 | |access-date = 24 February 2011 | ||
}}{{dead link|date=June 2023}}</ref> | }}{{dead link|date=June 2023}}</ref> | ||
===संख्यात्मक गणना के लिए कई बिंदुओं पर मूल्यांकन की आवश्यकता होती है=== | ===संख्यात्मक गणना के लिए कई बिंदुओं पर मूल्यांकन की आवश्यकता होती है=== | ||
| Line 141: | Line 138: | ||
सॉफ्टवेयर मॉड्यूल के बीच अंतरसंचालनीयता प्रदान करने के लिए थंक्स का व्यापक रूप से उपयोग किया गया है जिनकी दिनचर्या एक दूसरे को सीधे कॉल नहीं कर सकती है। ऐसा इसलिए हो सकता है क्योंकि रूटीन में अलग-अलग [[ सम्मलेन बुलाना ]] होते हैं, अलग-अलग [[सीपीयू मोड]] या [[ पता स्थान ]] में चलते हैं, या कम से कम एक [[ आभासी मशीन ]] में चलता है। एक कंपाइलर (या अन्य उपकरण) एक थंक उत्पन्न करके इस समस्या को हल कर सकता है जो लक्ष्य रूटीन को कॉल करने के लिए आवश्यक अतिरिक्त चरणों को स्वचालित करता है, चाहे वह तर्कों को बदलना हो, उन्हें किसी अन्य स्थान पर कॉपी करना हो, या सीपीयू मोड को स्विच करना हो। एक सफल थंक सामान्य कॉल की तुलना में कॉलर द्वारा किए जाने वाले अतिरिक्त काम को कम कर देता है। | सॉफ्टवेयर मॉड्यूल के बीच अंतरसंचालनीयता प्रदान करने के लिए थंक्स का व्यापक रूप से उपयोग किया गया है जिनकी दिनचर्या एक दूसरे को सीधे कॉल नहीं कर सकती है। ऐसा इसलिए हो सकता है क्योंकि रूटीन में अलग-अलग [[ सम्मलेन बुलाना ]] होते हैं, अलग-अलग [[सीपीयू मोड]] या [[ पता स्थान ]] में चलते हैं, या कम से कम एक [[ आभासी मशीन ]] में चलता है। एक कंपाइलर (या अन्य उपकरण) एक थंक उत्पन्न करके इस समस्या को हल कर सकता है जो लक्ष्य रूटीन को कॉल करने के लिए आवश्यक अतिरिक्त चरणों को स्वचालित करता है, चाहे वह तर्कों को बदलना हो, उन्हें किसी अन्य स्थान पर कॉपी करना हो, या सीपीयू मोड को स्विच करना हो। एक सफल थंक सामान्य कॉल की तुलना में कॉलर द्वारा किए जाने वाले अतिरिक्त काम को कम कर देता है। | ||
इंटरऑपरेबिलिटी थंक्स पर अधिकांश साहित्य [[MS-DOS]], | इंटरऑपरेबिलिटी थंक्स पर अधिकांश साहित्य [[MS-DOS|एमएस-डॉस]], ओएस/2 सहित विभिन्न [[विंटेल]] प्लेटफार्मों से संबंधित है।<ref name="Calcote_1995">{{cite journal |author-first=John |author-last=Calcote |title=थंकिंग: OS/2 2.0 में 16-बिट लाइब्रेरी का उपयोग करना|journal=OS/2 Developer Magazine |volume=7 |issue=3 |pages=48–56 |date=May 1995 |url=https://archive.org/details/Readme_20181018/OS2DevMag-V7N3/page/48/mode/2up}}</ref> [[ माइक्रोसॉफ़्ट विंडोज़ ]]़<ref name="King_1994">{{cite book |title=माइक्रोसॉफ्ट विंडोज 95 के अंदर|author-first=Adrian |author-last=King |publisher=[[Microsoft Press]] |edition=2nd |date=1994 |isbn=1-55615-626-X <!--|ISBN=978-1-55615-626-7 --> |location=Redmond, Washington, USA}}</ref><ref name="Microsoft_1995">{{cite book |title=माइक्रोसॉफ्ट विंडोज 95 के लिए प्रोग्रामर गाइड: माइक्रोसॉफ्ट विंडोज डेवलपमेंट टीम से विंडोज के लिए प्रोग्रामिंग पर मुख्य विषय|work=Technical Reference |author=<!-- staff writers --> |publisher=[[Microsoft Press]] |edition=1st |date=1995-07-01 |isbn=1-55615-834-3 <!--|ISBN=978-1-55615-834-6 --> |location=Redmond, Washington, USA |url=https://books.google.com/books?id=MLZQAAAAMAAJ |access-date=2016-05-26}}</ref><ref name="Hazzah_1997">{{cite book |title=विंडोज़ वीएक्सडी और डिवाइस ड्राइवर लिखना - वर्चुअल डिवाइस ड्राइवर्स के लिए प्रोग्रामिंग रहस्य|author-first=Karen |author-last=Hazzah |publisher=R&D Books / [[Miller Freeman, Inc.]] |location=Lawrence, Kansas, USA |edition=2nd printing, 2nd |date=1997 |isbn=0-87930-438-3 <!--|ISBN=978-0-87930-438-6 -->}}</ref><ref name="Kauler_1997">{{cite book |title=विंडोज असेंबली लैंग्वेज और सिस्टम प्रोग्रामिंग - पीसी और विंडोज के लिए 16- और 32-बिट लो-लेवल प्रोग्रामिंग|author-first=Barry |author-last=Kauler |author-link=Barry Kauler |publisher=R&D Books / [[Miller Freeman, Inc.]] |location=Lawrence, Kansas, USA |edition=2nd |date=August 1997 |isbn=0-87930-474-X <!--|ISBN=978-0-87930-474-4 -->}}</ref> और .नेट फ्रेमवर्क|.नेट, और [[16-बिट]] से [[32-बिट]] मेमोरी एड्रेसिंग में संक्रमण। चूँकि ग्राहक एक प्लेटफ़ॉर्म से दूसरे प्लेटफ़ॉर्म पर स्थानांतरित हो गए हैं, पुराने प्लेटफ़ॉर्म के लिए लिखे गए [[विरासत सॉफ्टवेयर]] का समर्थन करने के लिए थंक्स आवश्यक हो गए हैं। | ||
x86 पर 32-बिट से 64-बिट कोड में परिवर्तन भी थंकिंग (WoW64) के एक रूप का उपयोग करता है। | x86 पर 32-बिट से 64-बिट कोड में परिवर्तन भी थंकिंग (WoW64) के एक रूप का उपयोग करता है। यदपि, क्योंकि x86-64 पता स्थान 32-बिट कोड के लिए उपलब्ध स्थान से बड़ा है, पुराने जेनेरिक थंक तंत्र का उपयोग 32-बिट कोड से 64-बिट कोड को कॉल करने के लिए नहीं किया जा सकता है। रेफरी>{{cite web |title=आप 32-बिट और 64-बिट विंडोज़ के बीच विचार क्यों नहीं कर सकते?|url=https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20523 |website=पुरानी नई बात |date=20 अक्टूबर 2008}}</ref> 32-बिट कोड को 64-बिट कोड कॉल करने का एकमात्र मामला WoW64 द्वारा विंडोज एपीआई को 32-बिट में बदलना है। | ||
===ओवरले और डायनामिक लिंकिंग=== | ===ओवरले और डायनामिक लिंकिंग=== | ||
उन प्रणालियों पर जिनमें स्वचालित [[ आभासी मेमोरी ]] हार्डवेयर की कमी होती है, थंक्स वर्चुअल मेमोरी के एक सीमित रूप को लागू कर सकता है जिसे [[ओवरले (प्रोग्रामिंग)]] के रूप में जाना जाता है। ओवरले के साथ, एक डेवलपर प्रोग्राम के कोड को खंडों में विभाजित करता है जिन्हें स्वतंत्र रूप से लोड और अनलोड किया जा सकता है, और प्रत्येक खंड में [[प्रवेश बिंदु]]ओं की पहचान करता है। एक खंड जो दूसरे खंड में कॉल करता है उसे अप्रत्यक्ष रूप से [[शाखा तालिका]] के माध्यम से ऐसा करना होगा। जब कोई खंड मेमोरी में होता है, तो उसकी शाखा तालिका प्रविष्टियाँ खंड में चली जाती हैं। जब कोई खंड अनलोड किया जाता है, तो उसकी प्रविष्टियों को रीलोड थंक्स से बदल दिया जाता है जो मांग पर इसे पुनः लोड कर सकता है।<ref>{{cite journal|first=Walter|last=Bright|title=Virtual Memory For 640K DOS|journal=Dr. Dobb's Journal|date=1990-07-01|url=http://www.drdobbs.com/virtual-memory-for-640k-dos/184402189|access-date=2014-03-06}}</ref> | उन प्रणालियों पर जिनमें स्वचालित [[ आभासी मेमोरी ]] हार्डवेयर की कमी होती है, थंक्स वर्चुअल मेमोरी के एक सीमित रूप को लागू कर सकता है जिसे [[ओवरले (प्रोग्रामिंग)]] के रूप में जाना जाता है। ओवरले के साथ, एक डेवलपर प्रोग्राम के कोड को खंडों में विभाजित करता है जिन्हें स्वतंत्र रूप से लोड और अनलोड किया जा सकता है, और प्रत्येक खंड में [[प्रवेश बिंदु]]ओं की पहचान करता है। एक खंड जो दूसरे खंड में कॉल करता है उसे अप्रत्यक्ष रूप से [[शाखा तालिका]] के माध्यम से ऐसा करना होगा। जब कोई खंड मेमोरी में होता है, तो उसकी शाखा तालिका प्रविष्टियाँ खंड में चली जाती हैं। जब कोई खंड अनलोड किया जाता है, तो उसकी प्रविष्टियों को रीलोड थंक्स से बदल दिया जाता है जो मांग पर इसे पुनः लोड कर सकता है।<ref>{{cite journal|first=Walter|last=Bright|title=Virtual Memory For 640K DOS|journal=Dr. Dobb's Journal|date=1990-07-01|url=http://www.drdobbs.com/virtual-memory-for-640k-dos/184402189|access-date=2014-03-06}}</ref> | ||
इसी प्रकार, सिस्टम जो रन-टाइम पर किसी प्रोग्राम के मॉड्यूल को गतिशील रूप से जोड़ते हैं, मॉड्यूल को कनेक्ट करने के लिए थंक्स का उपयोग कर सकते हैं। प्रत्येक मॉड्यूल दूसरों को थंक्स की एक तालिका के माध्यम से कॉल कर सकता है जिसे लिंकर मॉड्यूल लोड करते समय भरता है। इस तरह मॉड्यूल पूर्व ज्ञान के बिना बातचीत कर सकते हैं कि वे मेमोरी में कहाँ स्थित हैं।<ref name="Levine_1999" /> | |||
==यह भी देखें== | ==यह भी देखें== | ||
===थंक टेक्नोलॉजीज=== | ===थंक टेक्नोलॉजीज=== | ||
* [[डॉस संरक्षित मोड इंटरफ़ेस]] ( | * [[डॉस संरक्षित मोड इंटरफ़ेस]] (डीपीएमआई) | ||
* [[डॉस संरक्षित मोड सेवाएँ]] ( | * [[डॉस संरक्षित मोड सेवाएँ]] (डीपीएमएस) | ||
* जे/डायरेक्ट | * जे/डायरेक्ट | ||
* यूनिकोड के लिए माइक्रोसॉफ्ट लेयर | * यूनिकोड के लिए माइक्रोसॉफ्ट लेयर | ||
| Line 164: | Line 160: | ||
===संबंधित अवधारणाएँ=== | ===संबंधित अवधारणाएँ=== | ||
* अनाम | * अनाम कार्य | ||
* [[वायदा और वादे]] | * [[वायदा और वादे]] | ||
* [[सुदूर प्रणाली संदेश]] | * [[सुदूर प्रणाली संदेश]] | ||
Revision as of 10:18, 18 July 2023
कंप्यूटर प्रोग्रामिंग में, थंक एक सबरूटीन है जिसका उपयोग किसी गणना को दूसरे सबरूटीन में इंजेक्ट करने के लिए किया जाता है। थंक्स का उपयोग मुख्य रूप से किसी गणना में देरी करने के लिए किया जाता है जब तक कि उसके परिणाम की आवश्यकता न हो, या अन्य सबरूटीन की आरम्भ या अंत में संचालन सम्मिलित करने के लिए किया जाता है। उनके पास कोड जनरेशन (कंपाइलर) और मॉड्यूलर प्रोग्रामिंग में कई अन्य अनुप्रयोग हैं।
यह शब्द सोचो क्रिया के सनकी अंग्रेजी अनियमित क्रिया रूप के रूप में उत्पन्न हुआ। यह एल्गोल 60 कंपाइलरों में थंक्स के मूल उपयोग को संदर्भित करता है, जिसे यह निर्धारित करने के लिए विशेष विश्लेषण (विचार) की आवश्यकता होती है कि किस प्रकार की दिनचर्या उत्पन्न की जाए।[1][2]
पृष्ठभूमि
संकलक अनुसंधान के प्रारंभिक वर्षों में विभिन्न मूल्यांकन रणनीति के साथ व्यापक प्रयोग देखा गया। एक महत्वपूर्ण प्रश्न यह था कि यदि तर्क स्थिरांक के बजाय मनमाने ढंग से गणितीय अभिव्यक्ति हो सकते हैं तो सबरूटीन कॉल को कैसे संकलित किया जाए। एक दृष्टिकोण, जिसे मूल्य के आधार पर कॉल करें के रूप में जाना जाता है, कॉल से पहले सभी तर्कों की गणना करता है और फिर परिणामी मानों को सबरूटीन में भेजता है। प्रतिद्वंद्वी नाम से बुलाओ दृष्टिकोण में, सबरूटीन को अमूल्यांकित तर्क अभिव्यक्ति प्राप्त होती है और उसे इसका मूल्यांकन करना चाहिए।
नाम से कॉल का एक सरल कार्यान्वयन सबरूटीन में संबंधित पैरामीटर की प्रत्येक उपस्थिति के लिए एक तर्क अभिव्यक्ति के कोड को प्रतिस्थापित कर सकता है, लेकिन यह सबरूटीन के कई संस्करण और अभिव्यक्ति कोड की कई प्रतियां उत्पन्न कर सकता है। एक सुधार के रूप में, कंपाइलर एक सहायक सबरूटीन उत्पन्न कर सकता है, जिसे थंक कहा जाता है, जो तर्क के मूल्य की गणना करता है। पता और वातावरण[lower-alpha 1] इस सहायक सबरूटीन को फिर मूल तर्क के स्थान पर मूल सबरूटीन में भेज दिया जाता है, जहां इसे आवश्यकतानुसार कई बार बुलाया जा सकता है। पीटर इंगरमैन ने सबसे पहले एल्गोल 60 प्रोग्रामिंग भाषा के संदर्भ में थंक्स का वर्णन किया, जो कॉल-बाय-नाम मूल्यांकन का समर्थन करता है।[4]
अनुप्रयोग
कार्यात्मक प्रोग्रामिंग
यदपि सॉफ्टवेयर उद्योग बड़े पैमाने पर कॉल-बाय-वैल्यू और संदर्भ द्वारा कॉल करें,कॉल-बाय-रेफरेंस मूल्यांकन पर मानकीकृत है,[5] कार्यात्मक प्रोग्रामिंग समुदाय में कॉल-बाय-नाम का सक्रिय अध्ययन प्रभावशील रहा। इस शोध ने आलसी मूल्यांकन प्रोग्रामिंग भाषाओं की एक श्रृंखला तैयार की जिसमें कॉल-बाय-नाम का कुछ प्रकार मानक मूल्यांकन रणनीति है। इन भाषाओं के लिए कंपाइलर, जैसे कि ग्लासगो हास्केल कंपाइलर, ने थंक्स पर बहुत अधिक भरोसा किया है, इसमें अतिरिक्त सुविधा यह है कि थंक्स अपने प्रारंभिक परिणाम को सहेजते हैं ताकि वे इसे पुनर्गणना करने से बच सकें;[6] इसे संस्मरण या मूल्यांकन रणनीति कॉल बाय नीड के रूप में जाना जाता है।
कार्यात्मक प्रोग्रामिंग भाषाओं ने प्रोग्रामर को स्पष्ट रूप से थंक्स उत्पन्न करने की भी अनुमति दी है। यह स्रोत कोड में एक अज्ञात कार्य में एक तर्क अभिव्यक्ति को लपेटकर किया जाता है जिसका अपना कोई पैरामीटर नहीं होता है। यह अभिव्यक्ति को तब तक मूल्यांकन करने से रोकता है जब तक कि प्राप्तकर्ता कार्य अज्ञात कार्य को कॉल नहीं करता है, जिससे कॉल-बाय-नाम के समान प्रभाव प्राप्त होता है।[7] अन्य प्रोग्रामिंग भाषाओं में अनाम कार्यों को अपनाने से यह क्षमता व्यापक रूप से उपलब्ध हो गई है।
निम्नलिखित जावास्क्रिप्ट (ईएस6) में एक सरल प्रदर्शन है:
// 'hypot' is a binary function
const hypot = (x, y) => Math.sqrt(x * x + y * y);
// 'thunk' is a function that takes no arguments and, when invoked, performs a potentially expensive
// operation (computing a square root, in this example) and/or causes some side-effect to occur
const thunk = () => hypot(3, 4);
// the thunk can then be passed around without being evaluated...
doSomethingWithThunk(thunk);
// ...or evaluated
thunk(); // === 5
वस्तु-उन्मुख प्रोग्रामिंग
थंक्स ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग प्लेटफ़ॉर्म में उपयोगी होते हैं जो एक क्लास (कंप्यूटर प्रोग्रामिंग) को एकाधिक इनहेरिटेंस की अनुमति देते हैं, जिससे ऐसी स्थिति उत्पन्न होती है जहां एक ही विधि (कंप्यूटर प्रोग्रामिंग) को कई इंटरफेस में से किसी एक के माध्यम से बुलाया जा सकता है। निम्नलिखित कोड सी++ में ऐसी स्थिति को दर्शाता है।
class A {
public:
virtual int Access() const { return value_; }
private:
int value_;
};
class B {
public:
virtual int Access() const { return value_; }
private:
int value_;
};
class C : public A, public B {
public:
int Access() const override { return better_value_; }
private:
int better_value_;
};
int use(B *b) { return b->Access(); }
int main() {
// ...
B some_b;
use(&some_b);
C some_c;
use(&some_c);
}
इस उदाहरण में, प्रत्येक वर्ग ए, बी और सी के लिए उत्पन्न कोड में एक प्रेषण तालिका सम्मिलित होगी जिसका उपयोग कॉल करने के लिए किया जा सकता है Access उस प्रकार की किसी वस्तु पर, उसी प्रकार के संदर्भ के माध्यम से। क्लास सी में एक अतिरिक्त डिस्पैच टेबल होगी, जिसका उपयोग कॉल करने के लिए किया जाएगा Access प्रकार बी के संदर्भ के माध्यम से प्रकार सी की एक वस्तु पर अभिव्यक्ति b->Access() बी की अपनी प्रेषण तालिका या अतिरिक्त सी तालिका का उपयोग करेगा, जो कि बी द्वारा संदर्भित ऑब्जेक्ट के प्रकार पर निर्भर करता है। यदि यह C प्रकार के ऑब्जेक्ट को संदर्भित करता है, तो कंपाइलर को यह सुनिश्चित करना होगा कि C Access कार्यान्वयन उस ऑब्जेक्ट के विरासत वाले बी भाग के बजाय संपूर्ण सी ऑब्जेक्ट के लिए यह (कंप्यूटर प्रोग्रामिंग) प्राप्त करता है।[8]
इस सूचक समायोजन समस्या के प्रत्यक्ष दृष्टिकोण के रूप में, कंपाइलर प्रत्येक प्रेषण तालिका प्रविष्टि में एक पूर्णांक ऑफसेट सम्मिलित कर सकता है। यह ऑफसेट संदर्भ के पते और विधि कार्यान्वयन के लिए आवश्यक पते के बीच का अंतर है। इन प्रेषण तालिकाओं के माध्यम से प्रत्येक कॉल के लिए उत्पन्न कोड को ऑफसेट पुनर्प्राप्त करना होगा और विधि को कॉल करने से पहले इंस्टेंस पते को समायोजित करने के लिए इसका उपयोग करना होगा।
अभी वर्णित समाधान में पहले वर्णित कॉल-बाय-नाम के सरल कार्यान्वयन के समान समस्याएं हैं: कंपाइलर एक तर्क (उदाहरण पता) की गणना करने के लिए कोड की कई प्रतियां उत्पन्न करता है, जबकि ऑफसेट को पकड़ने के लिए प्रेषण तालिका आकार भी बढ़ाता है। एक विकल्प के रूप में, कंपाइलर सी के कार्यान्वयन के साथ एक समायोजक थंक उत्पन्न कर सकता है Access जो इंस्टेंस एड्रेस को आवश्यक मात्रा से समायोजित करता है और फिर विधि को कॉल करता है। थंक बी के लिए सी की प्रेषण तालिका में दिखाई दे सकता है, जिससे कॉल करने वालों को पते को स्वयं समायोजित करने की आवश्यकता समाप्त हो जाती है।[9]
संख्यात्मक गणना के लिए कई बिंदुओं पर मूल्यांकन की आवश्यकता होती है
एकीकरण जैसी गणनाओं के लिए कई बिंदुओं पर एक अभिव्यक्ति की गणना करने की आवश्यकता होती है। नाम से कॉल का उपयोग इस उद्देश्य के लिए उन भाषाओं में किया गया था जो समापन (कंप्यूटर प्रोग्रामिंग) या प्रक्रियात्मक पैरामीटर का समर्थन नहीं करते थे।
इंटरऑपरेबिलिटी
सॉफ्टवेयर मॉड्यूल के बीच अंतरसंचालनीयता प्रदान करने के लिए थंक्स का व्यापक रूप से उपयोग किया गया है जिनकी दिनचर्या एक दूसरे को सीधे कॉल नहीं कर सकती है। ऐसा इसलिए हो सकता है क्योंकि रूटीन में अलग-अलग सम्मलेन बुलाना होते हैं, अलग-अलग सीपीयू मोड या पता स्थान में चलते हैं, या कम से कम एक आभासी मशीन में चलता है। एक कंपाइलर (या अन्य उपकरण) एक थंक उत्पन्न करके इस समस्या को हल कर सकता है जो लक्ष्य रूटीन को कॉल करने के लिए आवश्यक अतिरिक्त चरणों को स्वचालित करता है, चाहे वह तर्कों को बदलना हो, उन्हें किसी अन्य स्थान पर कॉपी करना हो, या सीपीयू मोड को स्विच करना हो। एक सफल थंक सामान्य कॉल की तुलना में कॉलर द्वारा किए जाने वाले अतिरिक्त काम को कम कर देता है।
इंटरऑपरेबिलिटी थंक्स पर अधिकांश साहित्य एमएस-डॉस, ओएस/2 सहित विभिन्न विंटेल प्लेटफार्मों से संबंधित है।[10] माइक्रोसॉफ़्ट विंडोज़ ़[11][12][13][14] और .नेट फ्रेमवर्क|.नेट, और 16-बिट से 32-बिट मेमोरी एड्रेसिंग में संक्रमण। चूँकि ग्राहक एक प्लेटफ़ॉर्म से दूसरे प्लेटफ़ॉर्म पर स्थानांतरित हो गए हैं, पुराने प्लेटफ़ॉर्म के लिए लिखे गए विरासत सॉफ्टवेयर का समर्थन करने के लिए थंक्स आवश्यक हो गए हैं।
x86 पर 32-बिट से 64-बिट कोड में परिवर्तन भी थंकिंग (WoW64) के एक रूप का उपयोग करता है। यदपि, क्योंकि x86-64 पता स्थान 32-बिट कोड के लिए उपलब्ध स्थान से बड़ा है, पुराने जेनेरिक थंक तंत्र का उपयोग 32-बिट कोड से 64-बिट कोड को कॉल करने के लिए नहीं किया जा सकता है। रेफरी>"आप 32-बिट और 64-बिट विंडोज़ के बीच विचार क्यों नहीं कर सकते?". पुरानी नई बात. 20 अक्टूबर 2008. {{cite web}}: Check date values in: |date= (help)</ref> 32-बिट कोड को 64-बिट कोड कॉल करने का एकमात्र मामला WoW64 द्वारा विंडोज एपीआई को 32-बिट में बदलना है।
ओवरले और डायनामिक लिंकिंग
उन प्रणालियों पर जिनमें स्वचालित आभासी मेमोरी हार्डवेयर की कमी होती है, थंक्स वर्चुअल मेमोरी के एक सीमित रूप को लागू कर सकता है जिसे ओवरले (प्रोग्रामिंग) के रूप में जाना जाता है। ओवरले के साथ, एक डेवलपर प्रोग्राम के कोड को खंडों में विभाजित करता है जिन्हें स्वतंत्र रूप से लोड और अनलोड किया जा सकता है, और प्रत्येक खंड में प्रवेश बिंदुओं की पहचान करता है। एक खंड जो दूसरे खंड में कॉल करता है उसे अप्रत्यक्ष रूप से शाखा तालिका के माध्यम से ऐसा करना होगा। जब कोई खंड मेमोरी में होता है, तो उसकी शाखा तालिका प्रविष्टियाँ खंड में चली जाती हैं। जब कोई खंड अनलोड किया जाता है, तो उसकी प्रविष्टियों को रीलोड थंक्स से बदल दिया जाता है जो मांग पर इसे पुनः लोड कर सकता है।[15]
इसी प्रकार, सिस्टम जो रन-टाइम पर किसी प्रोग्राम के मॉड्यूल को गतिशील रूप से जोड़ते हैं, मॉड्यूल को कनेक्ट करने के लिए थंक्स का उपयोग कर सकते हैं। प्रत्येक मॉड्यूल दूसरों को थंक्स की एक तालिका के माध्यम से कॉल कर सकता है जिसे लिंकर मॉड्यूल लोड करते समय भरता है। इस तरह मॉड्यूल पूर्व ज्ञान के बिना बातचीत कर सकते हैं कि वे मेमोरी में कहाँ स्थित हैं।[16]
यह भी देखें
थंक टेक्नोलॉजीज
- डॉस संरक्षित मोड इंटरफ़ेस (डीपीएमआई)
- डॉस संरक्षित मोड सेवाएँ (डीपीएमएस)
- जे/डायरेक्ट
- यूनिकोड के लिए माइक्रोसॉफ्ट लेयर
- प्लेटफ़ॉर्म मंगलाचरण सेवाएँ
- Win32s
- विंडोज़ पर विंडोज़
- वाह64
- libffi
संबंधित अवधारणाएँ
- अनाम कार्य
- वायदा और वादे
- सुदूर प्रणाली संदेश
- शिम (कंप्यूटिंग)
- ट्रैम्पोलिन (कंप्यूटिंग)
- कम करने योग्य अभिव्यक्ति
टिप्पणियाँ
संदर्भ
- ↑ Eric Raymond rejects "a couple of onomatopoeic myths circulating about the origin of this term" and cites the inventors of the thunk recalling that the term "was coined after they realized (in the wee hours after hours of discussion) that the type of an argument in Algol-60 could be figured out in advance with a little compile-time thought [...] In other words, it had 'already been thought of'; thus it was christened a thunk, which is 'the past tense of "think" at two in the morning'. See: Raymond, Eric S. (1996). Raymond, Eric S. (ed.). The New Hacker's Dictionary. MIT Press. p. 445. ISBN 9780262680929. Retrieved 2015-05-25.
- ↑ See Ingerman (1961): "The translator knows what kind of thunk to create by considering the formation of the actual parameter and the previously scanned declarations.… [W]hen a procedure declaration is being compiled, the translator, again by observing syntax, knows what kind of address to expect from a thunk."
- ↑ E. T. Irons (1961-01-01). "Comments on the Implementation of Recursive Procedures and Blocks in ALGOL". Communications of the ACM. Association for Computing Machinery (ACM). 4 (1): 65–69. doi:10.1145/366062.366084. ISSN 0001-0782. S2CID 14646332.
- ↑ Ingerman, P. Z. (1961-01-01). "Thunks: a way of compiling procedure statements with some comments on procedure declarations". Communications of the ACM. Association for Computing Machinery (ACM). 4 (1): 55–58. doi:10.1145/366062.366084. ISSN 0001-0782. S2CID 14646332.
- ↑ Scott, Michael (2009). प्रोग्रामिंग भाषा व्यावहारिकता. p. 395.
- ↑ Marlow, Simon (2013). हास्केल में समानांतर और समवर्ती प्रोग्रामिंग. p. 10.
- ↑ Queinnec, Christian (2003). छोटे टुकड़ों में लिस्प. p. 176.
- ↑ Stroustrup, Bjarne (Fall 1989). "Multiple Inheritance for C++" (PDF). Computing Systems. USENIX. 1 (4). Retrieved 2014-08-04.
- ↑ Driesen, Karel; Hölzle, Urs (1996). "The Direct Cost of Virtual Function Calls in C++" (PDF). Proceedings of the 1996 ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages & Applications, OOPSLA 1996, San Jose, California, USA, October 6-10, 1996. 11th OOPSLA 1996: San Jose, California, USA. ACM. ISBN 0-89791-788-X. Retrieved 2011-02-24.[dead link]
- ↑ Calcote, John (May 1995). "थंकिंग: OS/2 2.0 में 16-बिट लाइब्रेरी का उपयोग करना". OS/2 Developer Magazine. 7 (3): 48–56.
- ↑ King, Adrian (1994). माइक्रोसॉफ्ट विंडोज 95 के अंदर (2nd ed.). Redmond, Washington, USA: Microsoft Press. ISBN 1-55615-626-X.
- ↑ माइक्रोसॉफ्ट विंडोज 95 के लिए प्रोग्रामर गाइड: माइक्रोसॉफ्ट विंडोज डेवलपमेंट टीम से विंडोज के लिए प्रोग्रामिंग पर मुख्य विषय. 1995-07-01. ISBN 1-55615-834-3. Retrieved 2016-05-26.
{{cite book}}:|work=ignored (help) - ↑ Hazzah, Karen (1997). विंडोज़ वीएक्सडी और डिवाइस ड्राइवर लिखना - वर्चुअल डिवाइस ड्राइवर्स के लिए प्रोग्रामिंग रहस्य (2nd printing, 2nd ed.). Lawrence, Kansas, USA: R&D Books / Miller Freeman, Inc. ISBN 0-87930-438-3.
- ↑ Kauler, Barry (August 1997). विंडोज असेंबली लैंग्वेज और सिस्टम प्रोग्रामिंग - पीसी और विंडोज के लिए 16- और 32-बिट लो-लेवल प्रोग्रामिंग (2nd ed.). Lawrence, Kansas, USA: R&D Books / Miller Freeman, Inc. ISBN 0-87930-474-X.
- ↑ Bright, Walter (1990-07-01). "Virtual Memory For 640K DOS". Dr. Dobb's Journal. Retrieved 2014-03-06.
- ↑ Levine, John R. (2000) [October 1999]. Linkers and Loaders. The Morgan Kaufmann Series in Software Engineering and Programming (1 ed.). San Francisco, USA: Morgan Kaufmann. ISBN 1-55860-496-0. OCLC 42413382. Archived from the original on 2012-12-05. Retrieved 2020-01-12. Code: [1][2] Errata: [3]
