10 साल का अभ्यास। भाग 2: संसाधन

नमस्ते मैंने C ++ में संसाधन प्रबंधन पर एक बड़ा लेख लिखने की योजना बनाई।

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



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



संक्षेप में, तकनीक का सार वाक्यांश द्वारा वर्णित किया जा सकता है: "सब कुछ किसी का है।"

मेजबान वर्ग पूर्ण कार्य के लिए आवश्यक सभी संसाधनों को वहन करता है। उदाहरण के लिए:

हॉपर के नोड्स का वर्णन करने वाली वस्तुओं को हॉपर की श्रेणी में शामिल किया गया है। हेल्पर ऑब्जेक्ट्स, साथ ही जटिल गणना वर्ग के लिए डेटा ऑब्जेक्ट, इसमें शामिल हैं। और इसी तरह।

एक अपवाद कुछ वैश्विक चर हैं, जो सबसे बुनियादी वस्तुएं हैं। एक तरह से, और वे एक अनाम वैश्विक "वर्ग" के सदस्य हैं।



अब हम निम्नलिखित कहते हैं:

1. एक वस्तु को एक वर्ग के नियमित सदस्य के रूप में परिभाषित किया जाता है, या एक कंटेनर में रखा जाता है जो एक वर्ग का सदस्य होता है
2. संपत्ति का स्वामित्व हस्तांतरित नहीं किया जाता है

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





यदि वस्तु तुरंत नहीं बनाई गई है तो क्या होगा?

इस स्थिति में, आपको या तो एकल कंटेनर (जैसे कि unique_ptr) या एक सरणी कंटेनर की आवश्यकता होगी। उनका मुख्य कार्य विध्वंसक में किसी वस्तु का स्वत: विलोपन है। यह बात है!



और यहां हम रुकते हैं और सोचते हैं कि हमें क्या मिला।



1. हमने मैन्युअल कॉल नए / डिलीट से छुटकारा पा लिया। और उन्होंने इसे इतनी अच्छी तरह से छुटकारा दिलाया कि यहां तक ​​कि बाहरी अपवादों के मामले में, साथ ही साथ किसी भी अन्य स्थितियों में, हमारे संसाधनों को हटाए जाने की गारंटी दी जाएगी।



2. हमें एक बहुत अच्छा स्वचालित संसाधन प्रबंधन प्रणाली मिली जो कार्यक्रम के शब्दार्थ को ध्यान में रखती है।

उदाहरण के लिए, हमारे पास कई खिड़कियां हैं। कार्यक्रम के दौरान कुछ खिड़कियां नष्ट हो जाती हैं। यह उसके सभी संसाधनों को हटा देता है। हम उस पल को नियंत्रित करते हैं जब संसाधन हटा दिया जाता है, यह बहुत महत्वपूर्ण है।

हम कूड़ा उठाने वाले पर भरोसा नहीं करते हैं। हम निश्चित रूप से जानते हैं कि सही समय पर स्मृति को मुक्त कर दिया जाएगा।



आपको यह स्वीकार करना चाहिए कि निर्धारक संसाधन प्रबंधन किसी भी समय हटाने की प्रक्रिया पर ठोकर खाने की क्षमता के साथ एक बड़ा विपरीत है (जैसे, वीडियो चल रहा है, या आपको सर्वो को रोकने की आवश्यकता है), या सही समय पर संसाधन को हटाने के लिए कचरा कलेक्टर को व्यर्थ में हिला देने की क्षमता है।



3. जब होस्ट ऑब्जेक्ट अपने सदस्य को पॉइंटर जारी करता है, तो यह गारंटी दे सकता है कि इस पॉइंटर द्वारा वांछित वर्ग की आवश्यक वस्तु मौजूद है। जब हम ऐसे पॉइंटर का उपयोग करते हैं, तो हम होस्ट ऑब्जेक्ट के दायरे में काम करते हैं। इसका मतलब है कि हम सूचक की वैधता की गारंटी दे रहे हैं। क्या आप समझते हैं? पॉइंटर द्वारा ऑब्जेक्ट के जीवनकाल की गणना कंपाइलर द्वारा ही की जाती है, जो संकलन चरण में होस्ट ऑब्जेक्ट की दृश्यता की जांच करेगा।

यह लगभग एक सपना है: बिंदुओं के माध्यम से प्रभावी ढंग से काम करने के लिए, जिसकी वैधता संकलन चरण में जाँच की गई थी! और यह सब - ओवरहेड के बिना।



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



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



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



अब, संक्षेप में, क्या दृष्टिकोण है।



अब नुकसान के बारे में।

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



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



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



कृपया अशुद्धि को इंगित करें, कोशिश करें, आलोचना करें, आवेदन करें। मुझे किसी भी प्रतिक्रिया की खुशी होगी।



संदर्भ:

1. यू ++ अवलोकन ।



अगले हिस्से में बीवोर और जंगम वस्तुओं पर चर्चा करने का इरादा है। यह दिखाया जाएगा कि कैसे ये सुविधाएँ वस्तुओं के साथ काम करने की गति में उल्लेखनीय वृद्धि करती हैं। और उन पर आधारित कंटेनर एसटीएल की तुलना में 4-5 गुना तेज हैं ।

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