किसी वस्तु को सुरक्षित रूप से कैसे नष्ट किया जाए। और अन्य विचार

हाल ही में मैं एक प्रसिद्ध कार्यालय की रिक्तियों को देख रहा था, मैं मुद्दों के बारे में सोच रहा था (जो, वैसे, उनकी सभी रिक्तियों पर समान हैं)। और मैंने पहले प्रश्न के सबसे दिलचस्प (मेरी राय में) पहलू पर एक नोट लिखने का फैसला किया। हो सकता है कि मैं दूसरों के पास पहुंच जाऊं, लेकिन अब मैं यह सोचने का प्रस्ताव करता हूं कि क्या विध्वंसक को आभासी बनाना आवश्यक है?



उत्तर इतना स्पष्ट नहीं है, और आपको कटौती करने के लिए लुभाने के लिए, मैं कहूंगा कि एसटीएल कार्यान्वयन में आपको केवल कुछ आभासी विध्वंसक मिलेंगे।



विध्वंसक के बारे में सवाल का पूरा जवाब क्या होना चाहिए?

उन लोगों के लिए समस्या का सार जो आज तक नहीं हैं

इसलिए, यहां एक उदाहरण है, हर कोई पहले से ही ऊब गया है, गलत विध्वंसक का प्रतिनिधित्व कर रहा है:

 # किंकर्तव्यविमूढ़ <iostream>

 कक्षा ए {
 सार्वजनिक:
     A () {std :: cout << "A ()" << std :: endl;};
     ~ ए () {std :: cout << "~ A ()" << std :: endl;} // 6
 };

 वर्ग B: सार्वजनिक A {
 सार्वजनिक:
     B () {std :: cout << "B ()" << std :: endl;};
     ~ बी () {std :: cout << "~ B ()" << std :: endl;}
 };

 इंट मेन () {
     ए * ए = नया बी;  // 16
     हटा दें;  // 17
     वापसी 0;
 }

परिणाम यह है:

 ए ()
 बी ()
 ~ ए ()

अर्थात्, लाइन 16 पर कंस्ट्रक्टर बी ने ईमानदारी से दोनों बिल्डरों (ए और बी) को बुलाया, और लाइन 17 पर विध्वंसक को केवल क्लास ए डिस्ट्रक्टर कहा जाता है, जो पूरी तरह से लिंक किए गए लिंक के अनुरूप है।



सब कुछ सही ढंग से काम किया, लेकिन बी डिस्ट्रॉक्टर को नहीं बुलाया गया था, जिससे मेमोरी लीक, डिस्क्रिप्टर और अन्य उपयोगी संसाधन हो सकते हैं।



इससे कैसे निपटें?

सामान्य उत्तर एक आभासी विध्वंसक है

यदि लाइन 6 पर हम आभासी शब्द जोड़ते हैं:

 आभासी ~ ए () {एसटीडी :: कूट << "~ ए ()" << एसटीडी :: एंडल;} // 6

तब हर कोई खुश होगा

 ए ()
 बी ()
 ~ बी ()
 ~ ए ()

इस पर कई बार चर्चा हुई। बहुत अच्छे लेख थे। लेकिन मैं इस बात पर चर्चा करना चाहता हूं कि आभासी तरीके कैसे काम करते हैं, लेकिन अधिक दार्शनिक प्रश्न।

क्या आभासी तरीकों को सार्वजनिक करना अच्छा है?

आइए याद करें कि सार्वजनिक तरीके किसके लिए बनाए गए हैं । वे कक्षा के इंटरफ़ेस को परिभाषित करते हैं और उन लोगों के लिए बनाए जाते हैं जो कक्षा का उपयोग करेंगे ।



और इसके लिए आभासी तरीके क्या हैं? सही - वर्ग के व्यवहार को कॉन्फ़िगर करने के लिए। यही है, उन लोगों के लिए जो वर्ग की कार्यक्षमता का विस्तार करेंगे ।



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



निष्कर्ष: आभासी तरीकों को सार्वजनिक करना बहुत अच्छा नहीं है।



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



दूसरा सवाल:

क्या बहुरूपी वस्तुओं को नष्ट करना अच्छा है?

जैसा कि आप जानते हैं, जो कुछ भी बनाया गया था उसे हटा दिया जाना चाहिए। भ्रमित न होने के लिए, गलतियों को न करने के लिए, किसी भी चीज को भूल जाने और याद नहीं करने के लिए, आपको या तो वस्तुओं को हटाने की प्रक्रिया को स्वचालित करना होगा (स्वचालित चर, ऑटो_प्रटर और इसी तरह के कई उपकरण), या आपको वस्तुओं को उनके निर्माण के बिंदु से बहुत दूर नहीं हटाना चाहिए।



कहते हैं, यदि आप एक निश्चित कंटेनर के निर्माता में एक ऑब्जेक्ट (हीप पर) बनाते हैं, तो उसी ऑब्जेक्ट के विनाशकर्ता में इस ऑब्जेक्ट को हटाना उचित है। कृपया ध्यान दें कि इस मामले में बहुरूपी हटाने की कोई आवश्यकता नहीं है।



निष्कर्ष: बहुरूपी निष्कासन एक संदिग्ध चीज है।



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

इसके अलावा, वर्चुअल तरीके तुरंत कुछ सीमाएँ बनाते हैं।

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



निष्कर्ष: पहला आभासी तरीका बनाने से पहले, आप एक पल के लिए सोच सकते हैं: क्या हमें वास्तव में इसकी आवश्यकता है?

तो आदर्श आधार वर्ग विध्वंसक क्या होना चाहिए?

रूपक की तरह।



विध्वंसक गैर-आभासी और सार्वजनिक बनाने के लिए (जैसा कि पहले उदाहरण में) एमकेएडी पर रोलर स्केट्स की सवारी के समान है। एक एक अजीब आंदोलन नहीं है, हमारे पास चकमा देने का समय नहीं था और अब वीडियो अलग हैं, और आप अलग हैं ...



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



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



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



पेवर्स एक अच्छी चीज है। कभी-कभी उन्हें वास्तव में काम करने की आवश्यकता होती है। लेकिन यह परिवहन का एकमात्र तरीका नहीं है और इसके अलावा, उनका उपयोग करना अक्सर अधिक सुविधाजनक होता है।



तो उत्तर (पूर्ण):



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



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

नए साल में सभी खुश छुट्टियाँ और सफलता!

दिलचस्प सवालों के लिए एक प्रसिद्ध कंपनी का धन्यवाद। यह जानने के लिए उत्सुक होंगे कि उन्हें किस उत्तर की उम्मीद थी? उत्तर के लिए पहले से ही एक बहुत छोटा इनपुट क्षेत्र है। लेकिन मैंने उनके सवाल के जवाब के केवल एक हिस्से को छुआ।



अपडेट: इस लेख का उत्तर था। शायद मैं कुछ जवाब नहीं दूंगा। मुझे पहले ही इसका पता चल चुका है। लेखक, जाहिर है, अधिकार को मान्यता नहीं देता है। किताबें उसके लिए तर्क नहीं हैं। लेकिन नोट के रचनात्मक हिस्से में सामान्य रूप से विरासत के खतरों के बारे में बहुत सही विचार हैं। के रूप में कोडेक कारखाने के बारे में, जिसके बारे में लेखक अंत में लिखता है, वह इसके बारे में एक कहानी पढ़ने की उम्मीद कर सकता है, अगर मैं प्रश्नों के एक ही सेट से प्रश्न 4 के बारे में लिखने जा रहा हूं।



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