शुद्ध सी ++: कैसे ठीक से नष्ट करने के लिए

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

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

if(!Create1(...)) return -1; if(!Create2(...)) { Destroy1(...); return -1; } … if(!CreateN(...)) { Destroy1(...); Destroy2(...); ... DestroyN-1(...); return -1; } 

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

 #include <iostream> #include <stdexcept> class Foo { private: static int sm_count; int instance; public: Foo() { instance = ++sm_count; if(instance > 5) throw std::runtime_error("   5 ."); std::cout << " № " << instance << "  Foo .\n"; } ~Foo() { std::cout << " № " << instance << "  Foo .\n"; } }; int Foo::sm_count = 0; int main() { try { Foo* pFoo = new Foo[10]; } catch(const std::exception& e) { std::cout << e.what() << "\n"; } return 0; } 

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

 // HeaderFile1 class Interface1 { public: virtual void SomeFunc(int a) = 0; }; class Interface2 { public: virtual void AnotherFunc(double b) = 0; }; // HeaderFile2 class Implementation; class Storage { private: Implementation* m_pImpl; public: Storage(Implementation* in_pImpl) : m_pImpl(in_pImpl) {} Interface1* GetInterface1() { return (Interface1*)m_pImpl; } Interface2* GetInterface2() { return (Interface2*)m_pImpl; } }; // HeaderFile3 #include <iostream> class ImplementationBase { protected: virtual void BaseFunc() { std::cout << "BaseFunc  .\n"; } }; class Implementation : private ImplementationBase , public Interface1 , public Interface2 { public: virtual void SomeFunc(int a) { std::cout << "SomeFunc     a = " << a << ".\n"; } virtual void AnotherFunc(double b) { std::cout << "AnotherFunc     b = " << b << ".\n"; } }; // C++ source file // #include <HeaderFile1> // #include <HeaderFile2> // #include <HeaderFile3> int main() { Implementation impl; Storage storage(&impl); storage.GetInterface1()->SomeFunc(42); storage.GetInterface2()->AnotherFunc(37.7); return 0; } 

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

वापस विध्वंसकों के लिए। उन्हें लिखते समय, मुख्य बात यह नहीं है कि दुर्घटना से अपवाद को फेंकना नहीं है। तथ्य यह है कि अपवाद के प्रसंस्करण के दौरान विध्वंसक को ठीक कहा जा सकता है। इस मामले में, स्टैक को अनदेखा करने की प्रक्रिया के स्टैक को अनइंस्टॉल करने की प्रक्रिया सबसे सरल और सबसे अपेक्षित तरीके से समाप्त होती है: कार्यक्रम से तुरंत बाहर निकलें। इसलिए उन्हें करीब से देखें। किसी भी मामले में स्मृति, उनमें संसाधनों का आवंटन न करें, और इससे भी अधिक स्पष्ट रूप से अपवाद न फेंकें। यह आवश्यकता सभी "समापन" कार्यों के लिए एक निश्चित रवैया तय करती है। उदाहरण के लिए, कुछ Socket::Close() अब throw std::runtime_error("Close socket error: socket was not opened") सकते हैं। तथ्य यह है कि सबसे तार्किक चीज जिसे "समापन" फ़ंक्शन के साथ किया जा सकता है, उसे विनाशकारी में कॉल करना है। लेकिन विभिन्न स्थितियों की जाँच के साथ इस कॉल को लपेटना भी तर्कसंगत नहीं है। और यदि आप एक टीम में काम करते हैं, तो कोई निश्चित रूप से पहले से ही बंद को बंद करने की कोशिश करेगा। इसलिए, अपने लिए एक सरल नियम लिखें: किसी भी "समापन" फ़ंक्शन में आपको चुपचाप और अनावश्यक इशारों के बिना वही करना चाहिए जो इसके लिए आवश्यक है - जो पूछा जा रहा है उसे "बंद" करना, भले ही यह शारीरिक रूप से असंभव हो।
एक बार फिर, मैं इस तथ्य पर ध्यान आकर्षित करता हूं कि इस तरह के कार्यों और विनाशकारी में कुछ भी आवंटित या कब्जा नहीं किया जा सकता है। एक बहुत ही सामान्य गलती:

 ~object::object() { g_logger.put_message(std::string("Object ") + m_name + std::string(" was deleted.")); } 

यदि यह विध्वंसक "मेमोरी से बाहर" प्रकार के अपवाद के प्रसंस्करण के दौरान कहा जाता है, तो आप प्रोग्राम को लंबे समय तक क्रैश करने के लिए एक कारण की तलाश करेंगे। इसके अलावा, यहां तक ​​कि यहां वर्णित लकड़हारा भी मदद नहीं करेगा, क्योंकि वांछित संदेश बनाने और सहेजने में विफल रहता है। ऐसी स्थिति में कैसे हो? सबसे आसान तरीका है, लेकिन सबसे "सुंदर" एक नहीं है, अग्रिम में एक संदेश उत्पन्न करना है, जब सबकुछ ठीक था, और फिलहाल इसे निजी हिस्से में रखें। एक और "उन्नत" विकल्प:

 ~object::object() { g_logger << "Object " << m_name << " was deleted."; } 

मुझे उम्मीद है कि यह स्पष्ट है कि g_logger को यहाँ मेमोरी आवंटित करने और फ़ाइलों को खोलने का अधिकार नहीं है, लेकिन क्या यह एक निश्चित आकार के बफर के लिए तैयार है और पूर्ण होने पर इसे पहले से खोली गई फ़ाइल में मर्ज करना अनिवार्य है?

संसाधनों के आवंटन के लिए आगे बढ़ते हैं। सही दृष्टिकोण पहले प्रकाश डालना और फिर उपयोग करना है। यहाँ गलत उदाहरण है:

 std::vector<int> items; ... items.push_back(item1); items.push_back(item2);   : std::vector<int> items; ... items.reserve(items.size() + 2); items.push_back(item1); items.push_back(item2); 

आपको लगातार याद रखना चाहिए कि मेमोरी सबसे अधिक समय पर समाप्त हो सकती है, और ऐसे क्षण में कार्यक्रम की स्थिति को परिभाषित करना चाहिए। यदि सरणी में दो तत्व होने चाहिए, तो इसका अर्थ है कि दो पूर्णांक, या कोई भी नहीं। कोई "अविकसित" डेटा संरचनाएं नहीं होनी चाहिए, क्योंकि यह विनाशकारियों की विफलता का सीधा रास्ता है। एक अच्छा कार्यक्रम वह है जो स्मृति की कमी के साथ भी सही ढंग से अपने डेटा को बचाता है और चुपचाप छोड़ देता है। खैर, शायद चुपचाप नहीं, लेकिन विनम्रता से अलविदा कह रहे हैं। दुर्भाग्य से, यह हमेशा इतनी आसानी से हासिल नहीं होता है। उदाहरण के लिए, std::list में रिज़र्व विधि नहीं है। ऐसे मामलों के लिए, आपको डेटा आइटम की "खाली" स्थिति को शुरू करना होगा, जैसे कि पॉइंटर्स के लिए null_ptr या इंडेक्स के लिए -1, और इसे डेटा संरचना में पहले डालें। और विध्वंसक में, ऐसे तत्वों को ध्यान से बायपास करें। यहां सभी प्रकार के ऑपरेटरों के लिए जुनून को याद करना उचित है जो स्टैक पर अस्थायी ऑब्जेक्ट बनाते हैं। ये ऑब्जेक्ट, बदले में, आवंटित किए गए संसाधनों को आवंटित करते हैं, लेकिन एक जटिल अभिव्यक्ति के बीच में एक अपवाद अधिकार फेंक देते हैं, इस अभिव्यक्ति के कुछ हिस्सों को अर्ध-गणना की स्थिति में छोड़ देते हैं। उदाहरण के लिए, अभिव्यक्ति के बीच में ++ ऑपरेटर द्वारा स्थानांतरित किया गया एक पुनरावृत्ति पकड़ अनुभाग में पूरी तरह से बेकार हो जाएगा।

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

 typedef std::pair<int, int> DataItem; std::vector<DataItem> items; ... items.push_back(DataItem(item1, item2)); 

हालांकि, यह कार्य के विषय क्षेत्र को मॉडलिंग करने का इतना सरल विषय नहीं है।