फ़ाइनलाइज़र: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{for|वीडियो गेम|फाइनलाइज़र (वीडियो गेम)}} | {{for|वीडियो गेम|फाइनलाइज़र (वीडियो गेम)}} | ||
{{for|ऑप्टिकल डिस्क मीडिया से संबंधित प्रक्रिया|फाइनलाइज (ऑप्टिकल डिस्क)}} | {{for|ऑप्टिकल डिस्क मीडिया से संबंधित प्रक्रिया|फाइनलाइज (ऑप्टिकल डिस्क)}} | ||
[[कंप्यूटर विज्ञान]] में, | [[कंप्यूटर विज्ञान]] में, फाइनलाइज़र या अंतिम विधि एक विशेष [[विधि (कंप्यूटर प्रोग्रामिंग)]] है | जो अंतिम रूप देती है | सामान्यतः सफाई का कुछ रूप ऑब्जेक्ट के विनाश के समय फाइनलाइज़र को निष्पादित किया जाता है | [[वस्तु निर्माण|ऑब्जेक्ट निर्माण]] से पहले, और [[प्रारंभकर्ता]] का पूरक होता है | जिसे मेमोरी प्रबंधन के बाद ऑब्जेक्ट निर्माण के समय निष्पादित किया जाता है। उचित उपयोग में कठिनाई और उनके द्वारा जोड़ी जाने वाली जटिलता के कारण फ़ाइनलाइज़र को कुछ लोगों द्वारा दृढ़ता से हतोत्साहित किया जाता है, और इसके अतिरिक्त विकल्प सुझाए जाते हैं | मुख्य रूप से [[निपटान पैटर्न|डिस्पोजल समर्थन]] <ref>{{harvnb|Jagger|Perry|Sestoft|2007|p=[https://books.google.com/books?id=g6axWRRpJZwC&dq=destructor+finalizer&pg=PA542 542]|ps=, "In C++, a destructor is called in a determinate manner, whereas, in [[C Sharp (programming language)|C#]], a finalizer is not. To get determinate behavior from C#, one should use <code>Dispose.</code>}}</ref> (समस्याएं देखें) है। | ||
फ़ाइनलाइज़र शब्द का उपयोग अधिकतर [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग |ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] में किया जाता है। ऑब्जेक्ट-ओरिएंटेड और [[ कार्यात्मक प्रोग्रामिंग |कार्यात्मक प्रोग्रामिंग]] [[ प्रोग्रामिंग भाषा | प्रोग्रामिंग भाषा]] जो गारबेज संग्रह (कंप्यूटर साइंस) का उपयोग करती हैं | जिनमें से मूलरूप स्मॉलटाक है। यह [[ विनाशक (कंप्यूटर प्रोग्रामिंग) | विनाशक (कंप्यूटर प्रोग्रामिंग)]] के विपरीत है | जो नियतात्मक रूप से [[C++]] के नियतात्मक ऑब्जेक्ट जीवनकाल के साथ भाषाओं में अंतिम रूप देने के लिए कहा जाने वाला विधि है।<ref>{{cite conference |last=Boehm |first=Hans-J. |year=2002 |title=विध्वंसक, अंतिम रूप देने वाले और तुल्यकालन|url=http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html |conference=[[Symposium on Principles of Programming Languages]] (POPL)}}</ref><ref>{{harvnb|Jagger|Perry|Sestoft|2007|p=[https://books.google.com/books?id=g6axWRRpJZwC&dq=destructor+finalizer&pg=PA542 542]|ps=, '''C++ destructors versus C# finalizers''' C++ destructors are determinate in the sense that they are run at known points in time, in a known order, and from a known thread. They are thus semantically ''very'' different from C# finalizers, which are run at unknown points in time, in an unknown order, from an unknown thread, and at the discretion of the garbage collector.}}</ref> ये सामान्यतः अनन्य होते हैं | भाषा में या तो फ़ाइनलाइज़र (यदि स्वचालित रूप से गारबेज एकत्र किया जाता है) या विध्वंसक (यदि मैन्युअल रूप से मेमोरी प्रबंधित की जाती है), किन्तु दुर्लभ स्थितियों में भाषा में C++/CLI और D (प्रोग्रामिंग लैंग्वेज) और दोनों हो सकते हैं। [[संदर्भ गिनती|संदर्भ गणना]] का स्थिति (गारबेज संग्रह का पता लगाने के अतिरिक्त), शब्दावली अलग होती है। विधि उपयोग में, डिस्ट्रक्टर्स को संदर्भित करने के लिए फाइनलाइज़र का भी उपयोग किया जा सकता है | क्योंकि ये भी अंतिम रूप देते हैं, और कुछ सूक्ष्म भेद तैयार किए जाते हैं | शब्दावली देखें अंतिम शब्द का उपयोग उस वर्ग को इंगित करने के लिए भी किया जाता है | जो वंशानुक्रम (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) नहीं हो सकता है | यह असंबंधित है। | |||
== शब्दावली == | == शब्दावली == | ||
फाइनलाइज़र और फ़ाइनलाइज़ेशन बनाम विध्वंसक और विनाश की शब्दावली लेखकों के बीच अलग होती है और कभी-कभी अस्पष्ट होती है। | फाइनलाइज़र और फ़ाइनलाइज़ेशन बनाम विध्वंसक और विनाश की शब्दावली लेखकों के बीच अलग होती है और कभी-कभी अस्पष्ट होती है। | ||
सामान्य उपयोग में, | सामान्य उपयोग में, विध्वंसक एक विधि है | जिसे नियतात्मक रूप से ऑब्जेक्ट के विनाश पर कहा जाता है, और मूलरूप C++ विध्वंसक है | जबकि फाइनलाइज़र को गारबेज कलेक्टर द्वारा गैर-नियतात्मक रूप से कहा जाता है, और मूलरूप [[जावा (प्रोग्रामिंग भाषा)]] <code>finalize</code> को अंतिम रूप देने के विधि है | | ||
उन भाषाओं के लिए जो संदर्भ गिनती के माध्यम से गारबेज संग्रह को प्रयुक्त करती हैं | शब्दावली अलग होती है | कुछ भाषाओं जैसे [[ उद्देश्य सी | उद्देश्य C]] और [[पर्ल]] विनाशक का उपयोग करते हुए, और अन्य भाषाओं जैसे कि पायथन फ़ाइनलाइज़र का उपयोग करते हुए (प्रति युक्ति, पायथन गारबेज एकत्र किया जाता है, किन्तु संदर्भ [[CPython|C पायथन]] कार्यान्वयन इसके बाद से संस्करण 2.0 संदर्भ गिनती और गारबेज संग्रह के संयोजन का उपयोग करता है)। यह दर्शाता है कि संदर्भ गणना का परिणाम अर्ध-नियतात्मक ऑब्जेक्ट जीवनकाल में होता है | उन ऑब्जेक्ट के लिए जो | उन भाषाओं के लिए जो संदर्भ गिनती के माध्यम से गारबेज संग्रह को प्रयुक्त करती हैं | शब्दावली अलग होती है | कुछ भाषाओं जैसे [[ उद्देश्य सी |उद्देश्य C]] और [[पर्ल]] विनाशक का उपयोग करते हुए, और अन्य भाषाओं जैसे कि पायथन फ़ाइनलाइज़र का उपयोग करते हुए (प्रति युक्ति, पायथन गारबेज एकत्र किया जाता है, किन्तु संदर्भ [[CPython|C पायथन]] कार्यान्वयन इसके बाद से संस्करण 2.0 संदर्भ गिनती और गारबेज संग्रह के संयोजन का उपयोग करता है)। यह दर्शाता है कि संदर्भ गणना का परिणाम अर्ध-नियतात्मक ऑब्जेक्ट जीवनकाल में होता है | उन ऑब्जेक्ट के लिए जो चक्र का भाग नहीं हैं | ऑब्जेक्ट को निश्चित रूप से नष्ट कर दिया जाता है जब संदर्भ संख्या शून्य हो जाती है, किन्तु चक्र का भाग होने वाली ऑब्जेक्ट को गैर-नियतात्मक रूप से नष्ट कर दिया जाता है। गारबेज संग्रह के एक अलग रूप का भाग होता है । | ||
कुछ संकीर्ण विधि उपयोगों में, कंस्ट्रक्टर और विनाशक भाषा-स्तर के शब्द हैं | जिसका अर्थ है कि | कुछ संकीर्ण विधि उपयोगों में, कंस्ट्रक्टर और विनाशक भाषा-स्तर के शब्द हैं | जिसका अर्थ है कि वर्ग में परिभाषित विधियाँ, जबकि इनिशियलाइज़र और फ़ाइनलाइज़र कार्यान्वयन-स्तर की शर्तें हैं | जिसका अर्थ है ऑब्जेक्ट निर्माण या विनाश के समय बुलाई जाने वाली विधियाँ है। इस प्रकार उदाहरण के लिए C शार्प (प्रोग्रामिंग भाषा) के लिए मूल विनिर्देश C भाषा विनाशकों को संदर्भित करती है | तथापि C गारबेज-एकत्रित है, किन्तु सामान्य भाषा इंफ्रास्ट्रक्चर (सीएलआई) के लिए विनिर्देश, और इसके रनटाइम पर्यावरण के कार्यान्वयन के रूप में [[ सामान्य भाषा रनटाइम |सामान्य भाषा रनटाइम]] (सीएलआर), जिसे फाइनलाइजर्स कहा जाता है। यह C भाषा समिति के नोट्स में परिलक्षित होता है | जो भाग में पढ़ता है | C कंपाइलर डिस्ट्रक्टर्स को संकलित करता है | संभवतः उदाहरण फाइनलाइज़र एस <ref>In full: "We're going to use the term "destructor" for the member which executes when an instance is reclaimed. Classes can have destructors; structs can't. Unlike in C++, a destructor cannot be called explicitly. Destruction is non-deterministic – you can't reliably know when the destructor will execute, except to say that it executes at some point after all references to the object have been released. The destructors in an inheritance chain are called in order, from most descendant to least descendant. There is no need (and no way) for the derived class to explicitly call the base destructor. The C# compiler compiles destructors to the appropriate CLR representation. For this version that probably means an instance finalizer that is distinguished in metadata. CLR may provide static finalizers in the future; we do not see any barrier to C# using static finalizers.", May 12th, 1999.</ref><ref>[http://blogs.msdn.com/b/ericlippert/archive/2010/01/21/what-s-the-difference-between-a-destructor-and-a-finalizer.aspx What’s the difference between a destructor and a finalizer?], Eric Lippert, ''Eric Lippert’s Blog: Fabulous Adventures In Coding,'' 21 Jan 2010</ref> यह शब्दावली भ्रमित करने वाली है, और इस प्रकार C स्पेक के अधिक हाल के संस्करण भाषा-स्तरीय पद्धति को फ़ाइनलाइज़र के रूप में संदर्भित करते हैं।<ref name=csharpname/> | ||
एक अन्य भाषा जो d इस शब्दावली भेद को नहीं बनाती है | चूँकि d कक्षाएं गारबेज एकत्र की जाती हैं | उनके सफाई कार्यों को विध्वंसक कहा जाता है।<ref>[http://dlang.org/class.html#destructors Class destructors] Class destructors in D</ref> | एक अन्य भाषा जो d इस शब्दावली भेद को नहीं बनाती है | चूँकि d कक्षाएं गारबेज एकत्र की जाती हैं | उनके सफाई कार्यों को विध्वंसक कहा जाता है।<ref>[http://dlang.org/class.html#destructors Class destructors] Class destructors in D</ref> | ||
== प्रयोग == | == प्रयोग == | ||
फाइनलाइजेशन का उपयोग अधिकतर सफाई के लिए, मेमोरी या अन्य संसाधनों को जारी करने के लिए किया जाता है | [[ मैनुअल मेमोरी प्रबंधन ]] के माध्यम से आवंटित मेमोरी को हटाने के लिए; यदि संदर्भ गणना का उपयोग किया जाता है तो संदर्भों को स्पष्ट करने के लिए (संदर्भ संख्या में कमी) संसाधनों को जारी करने के लिए, विशेष रूप से संसाधन अधिग्रहण प्रारंभिक (आरएआईआई) मुहावरे में है | फाइनलाइजेशन का उपयोग अधिकतर सफाई के लिए, मेमोरी या अन्य संसाधनों को जारी करने के लिए किया जाता है | [[ मैनुअल मेमोरी प्रबंधन |मैनुअल मेमोरी प्रबंधन]] के माध्यम से आवंटित मेमोरी को हटाने के लिए; यदि संदर्भ गणना का उपयोग किया जाता है तो संदर्भों को स्पष्ट करने के लिए (संदर्भ संख्या में कमी) संसाधनों को जारी करने के लिए, विशेष रूप से संसाधन अधिग्रहण प्रारंभिक (आरएआईआई) मुहावरे में है या किसी ऑब्जेक्ट को अपंजीकृत करने के लिए अंतिम रूप देने की मात्रा भाषाओं के बीच महत्वपूर्ण रूप से अलग होती है | C++ में व्यापक अंतिमीकरण से, जिसमें मैनुअल स्मृति प्रबंधन, संदर्भ गणना, और नियतात्मक ऑब्जेक्ट जीवन काल होता है | जावा में अधिकाशतः कोई अंतिम रूप नहीं दिया जाता है, जिसमें गैर-नियतात्मक ऑब्जेक्ट जीवनकाल होता है और अधिकाशतः ट्रेसिंग गारबेज संग्राहक के साथ प्रयुक्त किया जाता है। यह भी संभव है कि कम या कोई स्पष्ट (उपयोगकर्ता-निर्दिष्ट) अंतिम रूप न हो, किन्तु संकलक, दुभाषिया, या रनटाइम द्वारा निष्पादित महत्वपूर्ण अंतर्निहित अंतिमकरण के स्थिति में यह सामान्य है | जैसा कि पायथन के सीपीथॉन संदर्भ कार्यान्वयन में, या ऐप्पल के ऑब्जेक्टिव-C के कार्यान्वयन में स्वचालित संदर्भ गणना में, जो दोनों अंतिम रूप से संदर्भों को स्वचालित रूप से तोड़ देते हैं। फाइनलाइज़र में मनमाना कोड सम्मिलित हो सकता है | विशेष रूप से जटिल उपयोग ऑब्जेक्ट को [[ वस्तु पूल |ऑब्जेक्ट पूल]] में स्वचालित रूप से वापस करना है। | ||
फाइनलाइजेशन के समय मेमोरी डीलोकेशन C++ जैसी भाषाओं में सामान्य है | जहां मैनुअल मेमोरी मैनेजमेंट मानक है, किन्तु प्रबंधित भाषाओं में भी होता है | जब मेमोरी को प्रबंधित हीप के बाहर आवंटित किया गया है |(बाह्य रूप से भाषा के लिए) जावा में यह [[ जावा मूल इंटरफ़ेस ]] (जेएनआई) और के साथ होता है | <code>ByteBuffer</code> नॉन-ब्लॉकिंग I/O (जावा) में ऑब्जेक्ट नया I/O (एनआईओ) यह उत्तरार्द्ध गारबेज संग्रहकर्ता के इन बाहरी संसाधनों को ट्रैक करने में असमर्थ होने के कारण समस्याएँ उत्पन्न कर सकता है | इसलिए उन्हें आक्रामक रूप से पर्याप्त रूप से एकत्र नहीं किया जाएगा, और अप्रबंधित मेमोरी को समाप्त करने के कारण आउट-ऑफ़-मेमोरी त्रुटियाँ उत्पन्न कर सकता है | देशी मेमोरी का इलाज करके इससे बचा जा सकता है | संसाधन के रूप में और डिस्पोजल समर्थन का उपयोग करते हुए, जैसा कि नीचे चर्चा की गई है। | फाइनलाइजेशन के समय मेमोरी डीलोकेशन C++ जैसी भाषाओं में सामान्य है | जहां मैनुअल मेमोरी मैनेजमेंट मानक है, किन्तु प्रबंधित भाषाओं में भी होता है | जब मेमोरी को प्रबंधित हीप के बाहर आवंटित किया गया है |(बाह्य रूप से भाषा के लिए) जावा में यह [[ जावा मूल इंटरफ़ेस |जावा मूल इंटरफ़ेस]] (जेएनआई) और के साथ होता है | <code>ByteBuffer</code> नॉन-ब्लॉकिंग I/O (जावा) में ऑब्जेक्ट नया I/O (एनआईओ) यह उत्तरार्द्ध गारबेज संग्रहकर्ता के इन बाहरी संसाधनों को ट्रैक करने में असमर्थ होने के कारण समस्याएँ उत्पन्न कर सकता है | इसलिए उन्हें आक्रामक रूप से पर्याप्त रूप से एकत्र नहीं किया जाएगा, और अप्रबंधित मेमोरी को समाप्त करने के कारण आउट-ऑफ़-मेमोरी त्रुटियाँ उत्पन्न कर सकता है | देशी मेमोरी का इलाज करके इससे बचा जा सकता है | संसाधन के रूप में और डिस्पोजल समर्थन का उपयोग करते हुए, जैसा कि नीचे चर्चा की गई है। | ||
फ़ाइनलाइज़र सामान्यतः बहुत कम आवश्यक होते हैं और विध्वंसक की तुलना में बहुत कम उपयोग किए जाते हैं। वे बहुत कम आवश्यक हैं क्योंकि गारबेज संग्रह स्मृति प्रबंधन को स्वचालित करता है, और बहुत कम उपयोग किया जाता है | क्योंकि वे सामान्यतः निश्चित रूप से निष्पादित नहीं होते हैं | उन्हें समय पर सही से या बिल्कुल भी नहीं बुलाया जा सकता है, और निष्पादन वातावरण की पूर्वानुमान नहीं की जा सकती है और इस प्रकार कोई भी क्लीनअप जो निश्चित रूप से किया जाना चाहिए | इसके अतिरिक्त किसी अन्य विधि द्वारा किया जाना चाहिए | अधिकाशतः मैन्युअल रूप से सेटलमेंट समर्थन के माध्यम से विशेष रूप से, जावा और पायथन दोनों इस बात की गारंटी नहीं देते हैं कि फाइनलाइजर्स को कभी भी बुलाया जाएगा, और इस प्रकार उन्हें सफाई के लिए विश्वास नहीं किया जा सकता है। | फ़ाइनलाइज़र सामान्यतः बहुत कम आवश्यक होते हैं और विध्वंसक की तुलना में बहुत कम उपयोग किए जाते हैं। वे बहुत कम आवश्यक हैं क्योंकि गारबेज संग्रह स्मृति प्रबंधन को स्वचालित करता है, और बहुत कम उपयोग किया जाता है | क्योंकि वे सामान्यतः निश्चित रूप से निष्पादित नहीं होते हैं | उन्हें समय पर सही से या बिल्कुल भी नहीं बुलाया जा सकता है, और निष्पादन वातावरण की पूर्वानुमान नहीं की जा सकती है और इस प्रकार कोई भी क्लीनअप जो निश्चित रूप से किया जाना चाहिए | इसके अतिरिक्त किसी अन्य विधि द्वारा किया जाना चाहिए | अधिकाशतः मैन्युअल रूप से सेटलमेंट समर्थन के माध्यम से विशेष रूप से, जावा और पायथन दोनों इस बात की गारंटी नहीं देते हैं कि फाइनलाइजर्स को कभी भी बुलाया जाएगा, और इस प्रकार उन्हें सफाई के लिए विश्वास नहीं किया जा सकता है। | ||
उनके निष्पादन पर प्रोग्रामर नियंत्रण की कमी के कारण, सामान्यतः किसी भी किन्तु सबसे सामान्य संचालन के लिए फाइनलाइज़र से बचने की पक्षसमर्थन की जाती है। विशेष रूप से, विध्वंसक में अधिकाशतः किए जाने वाले संचालन सामान्यतः अंतिम रूप देने वालों के लिए उपयुक्त नहीं होते हैं। | उनके निष्पादन पर प्रोग्रामर नियंत्रण की कमी के कारण, सामान्यतः किसी भी किन्तु सबसे सामान्य संचालन के लिए फाइनलाइज़र से बचने की पक्षसमर्थन की जाती है। विशेष रूप से, विध्वंसक में अधिकाशतः किए जाने वाले संचालन सामान्यतः अंतिम रूप देने वालों के लिए उपयुक्त नहीं होते हैं। सामान्य विरोधी प्रतिमान फाइनलाइज़र लिखना है जैसे कि वे विध्वंसक थे | जो अनावश्यक और अप्रभावी दोनों हैं | अंतिम रूप देने वालों और विध्वंसकों के बीच अंतर के कारण यह C++ प्रोग्रामर के बीच विशेष रूप से सामान्य है | क्योंकि रिसोर्स एक्विजिशन इज़ इनिशियलाइज़ेशन (आरएआईआई) मुहावरे के बाद मुहावरेदार C ++ में डिस्ट्रक्टर्स का भारी उपयोग किया जाता है। | ||
== वाक्य-विन्यास == | == वाक्य-विन्यास == | ||
फाइनलाइज़र का उपयोग करने [[जावास्क्रिप्ट (प्रोग्रामिंग भाषा)]] में C++/CLI, C तेज़ (प्रोग्रामिंग लैंग्वेज) C, [[ स्वच्छ (प्रोग्रामिंग भाषा) | क्लीन (प्रोग्रामिंग भाषा)]] , [[ जाओ (प्रोग्रामिंग भाषा) | जावा (प्रोग्रामिंग भाषा)]] , जावा (प्रोग्रामिंग लैंग्वेज), जावास्क्रिप्ट (प्रोग्रामिंग लैंग्वेज) और पायथन (प्रोग्रामिंग लैंग्वेज) सम्मिलित हैं। वाक्य-विन्यास भाषा के अनुसार अधिक अलग होता है। | फाइनलाइज़र का उपयोग करने [[जावास्क्रिप्ट (प्रोग्रामिंग भाषा)]] में C++/CLI, C तेज़ (प्रोग्रामिंग लैंग्वेज) C, [[ स्वच्छ (प्रोग्रामिंग भाषा) |क्लीन (प्रोग्रामिंग भाषा)]] , [[ जाओ (प्रोग्रामिंग भाषा) |जावा (प्रोग्रामिंग भाषा)]] , जावा (प्रोग्रामिंग लैंग्वेज), जावास्क्रिप्ट (प्रोग्रामिंग लैंग्वेज) और पायथन (प्रोग्रामिंग लैंग्वेज) सम्मिलित हैं। वाक्य-विन्यास भाषा के अनुसार अधिक अलग होता है। | ||
जावा में, फाइनलाइज़र | जावा में, फाइनलाइज़र विधि है जिसे <code>finalize</code> कहा जाता है | जो ओवरराइड <code>Object.finalize</code> विधि करता है।<ref name=java_Object.finalize>java.lang, क्लास ऑब्जेक्ट: [http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html# finalize() finalize]</ref> | ||
जावास्क्रिप्ट में, [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry finalizationRegistry] आपको किसी ऑब्जेक्ट के कूड़ा-गारबेज एकत्र करने पर कॉलबैक का अनुरोध करने की अनुमति देता है। | जावास्क्रिप्ट में, [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry finalizationRegistry] आपको किसी ऑब्जेक्ट के कूड़ा-गारबेज एकत्र करने पर कॉलबैक का अनुरोध करने की अनुमति देता है। | ||
पायथन में, फाइनलाइज़र | पायथन में, फाइनलाइज़र विधि है जिसे <code>__del__</code>. कहा जाता है | | ||
पर्ल में, फ़ाइनलाइज़र | पर्ल में, फ़ाइनलाइज़र विधि है | जिसे <code>DESTROY</code>. कहा जाता है | | ||
C में, | C में, अंतिमकर्ता (मानक के पुराने संस्करणों में विनाशक कहा जाता है) एक विधि है जिसका नाम <code>~</code> पूर्वसर्ग, के रूप में वर्ग का नाम है | जैसा कि <code>~Foo</code> में है | यह C++ विनाशक के समान सिंटैक्स है, और इन विधियों को मूल रूप से डिस्ट्रक्टर्स कहा जाता था, अलग-अलग व्यवहार होने के अतिरिक्त, C++ के साथ सादृश्य द्वारा, किन्तु इसके कारण होने वाले भ्रम के कारण इसका नाम बदलकर फाइनल कर दिया गया।<ref name=csharpname>{{harvnb|Jagger|Perry|Sestoft|2007|p=[https://books.google.com/books?id=g6axWRRpJZwC&dq=destructor+finalizer&pg=PA542 542]|ps=, "In the previous version of this standard, what is now referred to as a “finalizer” was called a “destructor”. Experience has shown that the term “destructor” caused confusion and often resulted in incorrect expectations, especially to programmers knowing C++. In C++, a destructor is called in a determinate manner, whereas, in C#, a finalizer is not. To get determinate behavior from C#, one should use <code>Dispose.</code>"}}</ref> | ||
C++/सीएलआई में, जिसमें विनाशक और फाइनलाइज़र दोनों हैं | | C++/सीएलआई में, जिसमें विनाशक और फाइनलाइज़र दोनों हैं | विनाशक एक विधि है जिसका नाम <code>~</code> पूर्वसर्ग, के रूप में वर्ग का नाम है | जैसा कि <code>~Foo</code> (C # में), और फाइनलाइज़र एक विधि है जिसका नाम <code>!</code> वर्ग का नाम है | जैसा कि पूर्वसर्ग, के रूप में <code>!Foo</code>. है | | ||
फाइनलाइजर्स को मानक पुस्तकालय में रनटाइम.<code>runtime.SetFinalizer</code> फ़ंक्शन को कॉल करके एकल सूचक पर लागू किया जाता है।<ref>{{Cite web|url=https://golang.org/pkg/runtime/#SetFinalizer|title=Runtime package - runtime - PKG.go.dev}}</ref> | फाइनलाइजर्स को मानक पुस्तकालय में रनटाइम.<code>runtime.SetFinalizer</code> फ़ंक्शन को कॉल करके एकल सूचक पर लागू किया जाता है।<ref>{{Cite web|url=https://golang.org/pkg/runtime/#SetFinalizer|title=Runtime package - runtime - PKG.go.dev}}</ref> | ||
== कार्यान्वयन == | == कार्यान्वयन == | ||
फाइनलाइज़र को तब कहा जाता है | जब | फाइनलाइज़र को तब कहा जाता है | जब [[वस्तु (कंप्यूटर विज्ञान)|ऑब्जेक्ट (कंप्यूटर विज्ञान)]] गारबेज एकत्र किया जाता है | ऑब्जेक्ट गारबेज (पहुंच योग्य) बनने के बाद, किन्तु इससे पहले कि उसकी मेमोरी को हटा दिया जाए। गारबेज संग्राहक के विवेक पर अंतिम रूप से गैर-नियतात्मक रूप से होता है, और कभी नहीं हो सकता है। यह विनाशकों के साथ विरोधाभासी है | जिन्हें नियतात्मक रूप से कहा जाता है | जैसे ही कोई ऑब्जेक्ट अब उपयोग में नहीं होती है, और अनियंत्रित कार्यक्रम समाप्ति के स्थिति को छोड़कर सदैव कहा जाता है। ऑब्जेक्ट-विशिष्ट संचालन करने की आवश्यकता के कारण फ़ाइनलाइज़र अधिकाशतः [[उदाहरण विधि]]याँ हैं। | ||
गारबेज संग्राहक को ऑब्जेक्ट के पुनरुत्थान की संभावना का भी ध्यान रखना चाहिए। सामान्यतः यह पहले फाइनलाइजर्स को निष्पादित करके किया जाता है | फिर जांच की जाती है कि क्या कोई ऑब्जेक्ट फिर से जीवित हो गई है, और यदि ऐसा है, तो उनके विनाश को रद्द कर दिया गया है। यह अतिरिक्त जांच संभावित रूप से महंगी है | साधारण कार्यान्वयन सभी कचरे की फिर से जाँच करता है | यदि एक भी ऑब्जेक्ट को अंतिम रूप दिया जाता है और इस तरह दोनों धीमा हो जाता है और गारबेज संग्रह को जटिल बना देता है। इस कारण से, फ़ाइनलाइज़र वाली ऑब्जेक्ट को फ़ाइनलाइज़र के बिना ऑब्जेक्ट की तुलना में कम बार एकत्र किया जा सकता है |(केवल कुछ चक्रों पर), संसाधन लीक जैसे शीघ्र अंतिमकरण पर निर्भर होने के कारण होने वाली समस्याओं को बढ़ा देता है। | गारबेज संग्राहक को ऑब्जेक्ट के पुनरुत्थान की संभावना का भी ध्यान रखना चाहिए। सामान्यतः यह पहले फाइनलाइजर्स को निष्पादित करके किया जाता है | फिर जांच की जाती है कि क्या कोई ऑब्जेक्ट फिर से जीवित हो गई है, और यदि ऐसा है, तो उनके विनाश को रद्द कर दिया गया है। यह अतिरिक्त जांच संभावित रूप से महंगी है | साधारण कार्यान्वयन सभी कचरे की फिर से जाँच करता है | यदि एक भी ऑब्जेक्ट को अंतिम रूप दिया जाता है और इस तरह दोनों धीमा हो जाता है और गारबेज संग्रह को जटिल बना देता है। इस कारण से, फ़ाइनलाइज़र वाली ऑब्जेक्ट को फ़ाइनलाइज़र के बिना ऑब्जेक्ट की तुलना में कम बार एकत्र किया जा सकता है |(केवल कुछ चक्रों पर), संसाधन लीक जैसे शीघ्र अंतिमकरण पर निर्भर होने के कारण होने वाली समस्याओं को बढ़ा देता है। | ||
| Line 52: | Line 49: | ||
== समस्याएं == | == समस्याएं == | ||
कार्यान्वयन के आधार पर, अंतिमकर्ता बड़ी संख्या में समस्याएं उत्पन्न कर सकते हैं, और इस प्रकार कई अधिकारियों द्वारा दृढ़ता से हतोत्साहित किया जाता है।<ref name=certjava>"[https://www.securecoding.cert.org/confluence/display/java/MET12-J.+Do+not+use+finalizers MET12-J. Do not use finalizers]", Dhruv Mohindra, [https://www.securecoding.cert.org/confluence/display/java The CERT Oracle Secure Coding Standard for Java], [https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=18580918 05. Methods (MET)] {{Webarchive|url=https://web.archive.org/web/20140504105218/https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=18580918 |date=2014-05-04 }}</ref><ref>[https://docs.python.org/3/reference/datamodel.html#object.__del__ object.__del__(self)], ''[https://docs.python.org/3/reference/ The Python Language Reference],'' [https://docs.python.org/3/reference/datamodel.html 3. Data model]: "... <code>__del__()</code> methods should do the absolute minimum needed to maintain external invariants."</ref> इन समस्याओं में सम्मिलित हैं |<ref name=certjava/> | कार्यान्वयन के आधार पर, अंतिमकर्ता बड़ी संख्या में समस्याएं उत्पन्न कर सकते हैं, और इस प्रकार कई अधिकारियों द्वारा दृढ़ता से हतोत्साहित किया जाता है।<ref name=certjava>"[https://www.securecoding.cert.org/confluence/display/java/MET12-J.+Do+not+use+finalizers MET12-J. Do not use finalizers]", Dhruv Mohindra, [https://www.securecoding.cert.org/confluence/display/java The CERT Oracle Secure Coding Standard for Java], [https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=18580918 05. Methods (MET)] {{Webarchive|url=https://web.archive.org/web/20140504105218/https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=18580918 |date=2014-05-04 }}</ref><ref>[https://docs.python.org/3/reference/datamodel.html#object.__del__ object.__del__(self)], ''[https://docs.python.org/3/reference/ The Python Language Reference],'' [https://docs.python.org/3/reference/datamodel.html 3. Data model]: "... <code>__del__()</code> methods should do the absolute minimum needed to maintain external invariants."</ref> इन समस्याओं में सम्मिलित हैं |<ref name=certjava/> फाइनलाइजर्स को समय पर या बिल्कुल भी नहीं बुलाया जा सकता है | इसलिए उन पर स्तर को जारी रखने, दुर्लभ संसाधनों को जारी करने, या कुछ और महत्वपूर्ण करने के लिए विश्वास नहीं किया जा सकता है। | ||
* फ़ाइनलाइज़र का परिणाम ऑब्जेक्ट पुनरुत्थान हो सकता है | जो अधिकाशतः | * फ़ाइनलाइज़र का परिणाम ऑब्जेक्ट पुनरुत्थान हो सकता है | जो अधिकाशतः प्रोग्रामिंग त्रुटि होती है और जिसकी बहुत संभावना अधिक धीमी हो जाती है और गारबेज संग्रहण को जटिल बना देती है। | ||
* फाइनलाइज़र गारबेज संग्रह के आधार पर चलाए जाते हैं \ जो सामान्यतः प्रबंधित मेमोरी दबाव पर आधारित होते हैं | वे अन्य संसाधनों की कमी के स्थिति में नहीं चलते हैं, और इस प्रकार अन्य दुर्लभ संसाधनों के प्रबंधन के लिए उपयुक्त नहीं होते हैं। | * फाइनलाइज़र गारबेज संग्रह के आधार पर चलाए जाते हैं \ जो सामान्यतः प्रबंधित मेमोरी दबाव पर आधारित होते हैं | वे अन्य संसाधनों की कमी के स्थिति में नहीं चलते हैं, और इस प्रकार अन्य दुर्लभ संसाधनों के प्रबंधन के लिए उपयुक्त नहीं होते हैं। | ||
* फ़ाइनलाइज़र | * फ़ाइनलाइज़र निर्दिष्ट क्रम में नहीं चलते हैं, और [[ वर्ग अपरिवर्तनीय |वर्ग अपरिवर्तनीय]] पर विश्वास नहीं कर सकते हैं (क्योंकि वे अन्य ऑब्जेक्ट्स को संदर्भित कर सकते हैं | जिन्हें पहले ही अंतिम रूप दिया जा चुका है)। | ||
* धीमे फाइनलाइज़र अन्य फ़ाइनलाइज़र में देरी कर सकते हैं। | * धीमे फाइनलाइज़र अन्य फ़ाइनलाइज़र में देरी कर सकते हैं। | ||
* फ़ाइनलाइज़र के अपवादों को सामान्यतः नियंत्रित नहीं किया जा सकता है | क्योंकि फ़ाइनलाइज़र | * फ़ाइनलाइज़र के अपवादों को सामान्यतः नियंत्रित नहीं किया जा सकता है | क्योंकि फ़ाइनलाइज़र अनिर्दिष्ट वातावरण में चलाया जाता है, और इसे या तो अनदेखा किया जा सकता है या अनियंत्रित प्रोग्राम समाप्ति का कारण बन सकता है। | ||
* फ़ाइनलाइज़र प्रोग्राम इनवेरिएंट्स का उल्लंघन करते हुए लाइव ऑब्जेक्ट्स को संदर्भित और गलती से अंतिम रूप दे सकते हैं। | * फ़ाइनलाइज़र प्रोग्राम इनवेरिएंट्स का उल्लंघन करते हुए लाइव ऑब्जेक्ट्स को संदर्भित और गलती से अंतिम रूप दे सकते हैं। | ||
* फाइनलाइज़र सिंक्रनाइज़ेशन मुद्दों का कारण बन सकता है | यहां तक कि अनुक्रमिक (एकल-थ्रेडेड) कार्यक्रमों में भी, जब एक अलग धागे में अंतिम रूप दिया जाता है।<ref>Hans-J. Boehm, Finalization, Threads, and the Java™ Technology-Based Memory Model, JavaOne Conference, 2005.</ref> | * फाइनलाइज़र सिंक्रनाइज़ेशन मुद्दों का कारण बन सकता है | यहां तक कि अनुक्रमिक (एकल-थ्रेडेड) कार्यक्रमों में भी, जब एक अलग धागे में अंतिम रूप दिया जाता है।<ref>Hans-J. Boehm, Finalization, Threads, and the Java™ Technology-Based Memory Model, JavaOne Conference, 2005.</ref> | ||
* फ़ाइनलाइज़र डेडलॉक का कारण बन सकता है | यदि सिंक्रोनाइज़ेशन मैकेनिज़्म जैसे ताले का उपयोग किया जाता है | | * फ़ाइनलाइज़र डेडलॉक का कारण बन सकता है | यदि सिंक्रोनाइज़ेशन मैकेनिज़्म जैसे ताले का उपयोग किया जाता है | निर्दिष्ट क्रम में नहीं चलने और संभवतः समवर्ती रूप से चलने के कारण होता है। | ||
* प्रोग्राम समाप्ति के समय चलाए जाने वाले फ़ाइनलाइज़र सामान्य रनटाइम वातावरण पर विश्वास नहीं कर सकते हैं, और इस प्रकार गलत धारणाओं के कारण विफल हो सकते हैं इस कारण फ़ाइनलाइज़र अधिकाशतः समाप्ति के समय नहीं चलते हैं। | * प्रोग्राम समाप्ति के समय चलाए जाने वाले फ़ाइनलाइज़र सामान्य रनटाइम वातावरण पर विश्वास नहीं कर सकते हैं, और इस प्रकार गलत धारणाओं के कारण विफल हो सकते हैं इस कारण फ़ाइनलाइज़र अधिकाशतः समाप्ति के समय नहीं चलते हैं। | ||
इसके अतिरिक्त, प्रोग्रामिंग त्रुटियों के कारण या अप्रत्याशित रीचैबिलिटी के कारण गारबेज होने की उम्मीद से परे पहुंच योग्य ऑब्जेक्ट के कारण अंतिम रूप से चलने में विफल हो सकते हैं। उदाहरण के लिए, जब पायथन | इसके अतिरिक्त, प्रोग्रामिंग त्रुटियों के कारण या अप्रत्याशित रीचैबिलिटी के कारण गारबेज होने की उम्मीद से परे पहुंच योग्य ऑब्जेक्ट के कारण अंतिम रूप से चलने में विफल हो सकते हैं। उदाहरण के लिए, जब पायथन अपवाद को पकड़ता है (या अपवाद इंटरएक्टिव मोड में नहीं पकड़ा जाता है), यह स्टैक फ्रेम का संदर्भ रखता है | जहां अपवाद उठाया गया था | जो उस स्टैक फ्रेम से संदर्भित ऑब्जेक्ट को जीवित रखता है। | ||
जावा में, | जावा में, सुपरक्लास में फ़ाइनलाइज़र उपवर्ग में गारबेज संग्रह को धीमा कर सकता है | क्योंकि फ़ाइनलाइज़र संभावित रूप से उपवर्ग में फ़ील्ड्स को संदर्भित कर सकता है, और इस प्रकार फ़ाइनलाइज़र के चलने के बाद, अगले चक्र तक फ़ील्ड को गारबेज एकत्र नहीं किया जा सकता है।<ref name=certjava/> [[वंशानुक्रम पर रचना]] का उपयोग करके इससे बचा जा सकता है। | ||
== संसाधन प्रबंधन == | == संसाधन प्रबंधन == | ||
{{main|संसाधन प्रबंधन (कंप्यूटिंग)}} | {{main|संसाधन प्रबंधन (कंप्यूटिंग)}} | ||
संसाधनों को जारी करने के लिए फ़ाइनलाइज़र का उपयोग करने के लिए | संसाधनों को जारी करने के लिए फ़ाइनलाइज़र का उपयोग करने के लिए सामान्य एंटी-समर्थन है | C ++ के रिसोर्स एक्विजिशन इज़ इनिशियलाइज़ेशन (आरएआईआई) मुहावरे के अनुरूप: इनिशियलाइज़र (कन्स्ट्रक्टर) में संसाधन प्राप्त करें, और इसे फ़ाइनलाइज़र (विनाशक) में रिलीज़ करें। यह कई कारणों से काम नहीं करता है। मूल रूप से, अंतिम रूप देने वालों को कभी नहीं बुलाया जा सकता है, और यहां तक कि यदि बुलाया जाता है, तो उन्हें समय पर सही से नहीं बुलाया जा सकता है | इस प्रकार संसाधनों को जारी करने के लिए अंतिम रूप देने वालों का उपयोग सामान्यतः [[संसाधन रिसाव] | ||