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

सामग्री की तालिका

परिचय

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

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

इंटरफ़ेस कक्षाएं काफी व्यापक रूप से उपयोग की जाती हैं, उनकी मदद से वे पुस्तकालयों (एसडीके) के इंटरफ़ेस (एपीआई) को लागू करते हैं, प्लग-इन (प्लगइन्स) का इंटरफ़ेस और बहुत कुछ। कई गैंग ऑफ़ फोर [GoF] पैटर्न को स्वाभाविक रूप से इंटरफ़ेस कक्षाओं का उपयोग करके लागू किया जाता है। इंटरफ़ेस कक्षाओं में COM इंटरफेस शामिल हैं। लेकिन, दुर्भाग्य से, इंटरफ़ेस कक्षाओं के आधार पर समाधान को लागू करते समय अक्सर गलतियां की जाती हैं। आइए इस मुद्दे को स्पष्ट करने का प्रयास करें।

1. विशेष सदस्य कार्य, ऑब्जेक्ट बनाना और हटाना

यह खंड संक्षेप में कई सी ++ विशेषताओं का वर्णन करता है जिन्हें आपको इंटरफ़ेस कक्षाओं के लिए पेश किए गए समाधानों को पूरी तरह से समझने के लिए जानना आवश्यक है।

1.1। विशेष सदस्य के कार्य

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

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

प्रोग्रामर विशेष सदस्य कार्यों की पीढ़ी को प्रतिबंधित कर सकता है, C ++ 11 में घोषणा करते समय "=delete" निर्माण का उपयोग करना आवश्यक है, C ++ 98 में संबंधित सदस्य फ़ंक्शन को निजी घोषित करें और परिभाषित न करें। क्लास इनहेरिटेंस में, बेस क्लास में किए गए एक विशेष सदस्य फ़ंक्शन को जेनरेट करने की मनाही सभी व्युत्पन्न वर्गों पर लागू होती है।

यदि प्रोग्रामर संकलक द्वारा उत्पन्न सदस्य कार्यों के साथ सहज है, तो C ++ 11 में वह इसे स्पष्ट रूप से इंगित कर सकता है, न कि केवल घोषणा को छोड़ दें। ऐसा करने के लिए, आपको घोषणा करते समय "=default" निर्माण का उपयोग करना चाहिए, जबकि कोड बेहतर पढ़ा जाता है और अतिरिक्त स्तर एक्सेस स्तर के प्रबंधन से संबंधित दिखाई देते हैं।

विशेष सदस्य कार्यों पर विवरण [Meyers3] में पाया जा सकता है।

1.2। वस्तुओं को बनाना और हटाना - मूल विवरण

new/delete ऑपरेटरों का उपयोग करके ऑब्जेक्ट बनाना और हटाना एक विशिष्ट टू-इन-वन ऑपरेशन है। new कॉल new , मेमोरी को पहले ऑब्जेक्ट के लिए आवंटित किया जाता है। यदि चयन सफल होता है, तो निर्माता को बुलाया जाता है। यदि निर्माता एक अपवाद फेंकता है, तो आवंटित मेमोरी को मुक्त कर दिया जाता है। जब delete ऑपरेटर को कॉल किया जाता है, तो सब कुछ रिवर्स ऑर्डर में होता है: पहले, डिस्ट्रक्टर को बुलाया जाता है, फिर मेमोरी को मुक्त किया जाता है। विध्वंसक को अपवाद नहीं फेंकना चाहिए।

यदि new ऑपरेटर का उपयोग वस्तुओं की एक सरणी बनाने के लिए किया जाता है, तो मेमोरी को पहले पूरे सरणी के लिए आवंटित किया जाता है। यदि चयन सफल होता है, तो डिफ़ॉल्ट कंस्ट्रक्टर को शून्य से शुरू होने वाले सरणी के प्रत्येक तत्व के लिए कहा जाता है। यदि कोई भी कंस्ट्रक्टर अपवाद फेंकता है, तो सरणी के सभी बनाए गए तत्वों के लिए विध्वंसक को कंस्ट्रक्टर कॉल के रिवर्स ऑर्डर में बुलाया जाता है, फिर आवंटित मेमोरी को मुक्त कर दिया जाता है। किसी सरणी को हटाने के लिए, आपको delete[] ऑपरेटर (सरणियों के लिए delete ऑपरेटर कहा जाता है) को कॉल करना होगा, और सरणी के सभी तत्वों के लिए, विध्वंसक को कंस्ट्रक्टर कॉल के रिवर्स ऑर्डर में बुलाया जाता है, फिर आवंटित मेमोरी को मुक्त कर दिया जाता है।

चेतावनी! आपको delete ऑपरेटर का सही फॉर्म कॉल करना होगा, यह इस बात पर निर्भर करता है कि कोई ऑब्जेक्ट या एरे डिलीट है या नहीं। इस नियम को सख्ती से देखा जाना चाहिए, अन्यथा आप अपरिभाषित व्यवहार प्राप्त कर सकते हैं, अर्थात, कुछ भी हो सकता है: स्मृति लीक, दुर्घटना, आदि। जानकारी के लिए [Meyers2] देखें।

मानक मेमोरी आवंटन फ़ंक्शन प्रकार std::bad_alloc अपवाद को फेंकने के अनुरोध को पूरा करने में std::bad_alloc होते हैं।

delete ऑपरेटर के किसी भी रूप को नल पॉइंटर में लागू करना सुरक्षित है।

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

1.3। विध्वंसक पहुंच स्तर

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

1.4। एक मॉड्यूल बनाएं और हटाएं

यदि new ऑपरेटर ने कोई ऑब्जेक्ट बनाया है, तो उसे delete लिए delete ऑपरेटर उसी मॉड्यूल में होना चाहिए। आंकिक रूप से बोलते हुए, "जहां आपने इसे लिया था, उसे डाल दिया।" यह नियम सर्वविदित है; उदाहरण के लिए, [सटर / अलेक्जेंड्रेस्कु] देखें। यदि इस नियम का उल्लंघन किया जाता है, तो स्मृति को आवंटित करने और मुक्त करने के कार्यों का एक "बेमेल" हो सकता है, जो एक नियम के रूप में, कार्यक्रम की असामान्य समाप्ति की ओर जाता है।

1.5। बहुरूपी विलोपन

यदि आप उन वर्गों की बहुरूपी पदानुक्रम डिज़ाइन कर रहे हैं जिनके इंस्टेंस को डिलीट ऑपरेटर का उपयोग करके हटा दिया जाता है, तो बेस क्लास में एक खुला वर्चुअल डिस्ट्रक्टर होना चाहिए, इससे सुनिश्चित होता है कि delete ऑपरेटर को बेस क्लास में पॉइंटर पर लागू करने पर वास्तविक प्रकार की ऑब्जेक्ट के डिस्ट्रक्टर को कहा जाता है। यदि इस नियम का उल्लंघन किया जाता है, तो बेस क्लास डिस्ट्रक्टर को कॉल किया जा सकता है, जिससे रिसोर्स लीक हो सकता है।

1.6। वर्ग घोषणा अपूर्ण होने पर हटाना

delete ऑपरेटर की सर्वव्यापीता कुछ समस्याएं पैदा कर सकती है; इसे टाइप void* पॉइंटर पर लगाया जा सकता है या एक पॉइंटर को पॉइंटर में अधूरा (प्रीमेप्टिव) घोषित किया जा सकता है। इस स्थिति में, कोई त्रुटि उत्पन्न नहीं होती है, बस विध्वंसक को कॉल छोड़ दिया जाता है, केवल मेमोरी को मुक्त करने का कार्य कहा जाता है। एक उदाहरण पर विचार करें:

 class X; //   X* CreateX(); void Foo() {    X* p = CreateX();    delete p; } 

यह कोड उस समय भी संकलित करता है, जब delete डायल पीयर पर एक पूर्ण X श्रेणी की घोषणा उपलब्ध नहीं है। सच है, जब संकलन (विजुअल स्टूडियो) एक चेतावनी जारी की जाती है:

warning C4150: deletion of pointer to incomplete type 'X'; no destructor called

यदि X और CreateX() का कार्यान्वयन होता है, तो कोड CreateX() , यदि CreateX() new ऑपरेटर द्वारा बनाई गई ऑब्जेक्ट को एक पॉइंटर लौटाता है, तो Foo() सफलतापूर्वक निष्पादित किया जाता है, विध्वंसक नहीं कहा जाता है। यह स्पष्ट है कि इससे संसाधनों की कमी हो सकती है, इसलिए एक बार फिर चेतावनी के बारे में सावधान रहने की आवश्यकता है।

यह स्थिति दूर की कौड़ी नहीं है, यह स्मार्ट पॉइंटर्स या डिस्क्रिप्टर क्लास जैसी कक्षाओं का उपयोग करते समय आसानी से उत्पन्न हो सकती है। स्कॉट मेयर्स [Meyers3] में इस मुद्दे से निपटते हैं।

2. विशुद्ध रूप से आभासी कार्य और अमूर्त वर्ग

इंटरफ़ेस कक्षाओं की अवधारणा ऐसी सी ++ अवधारणाओं पर आधारित है जो शुद्ध आभासी कार्यों और सार कक्षाओं के रूप में होती है।

2.1। शुद्ध आभासी कार्य

"=0" निर्माण का उपयोग करके घोषित एक आभासी फ़ंक्शन को शुद्ध आभासी कहा जाता है।

 class X { // ...    virtual void Foo() = 0; }; 

एक नियमित वर्चुअल फ़ंक्शन के विपरीत, एक विशुद्ध रूप से वर्चुअल फ़ंक्शन को परिभाषित नहीं किया जा सकता (विध्वंसक के अपवाद के साथ, खंड 2.3 देखें), लेकिन इसे व्युत्पन्न वर्गों में से एक में फिर से परिभाषित किया जाना चाहिए।

विशुद्ध रूप से आभासी कार्यों को परिभाषित किया जा सकता है। प्रतीक Sutter इस सुविधा [शटर] के लिए कई उपयोगी उपयोग प्रदान करता है।

2.2। सार वर्ग

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

2.3। शुद्ध आभासी विध्वंसक

कुछ मामलों में, शुद्ध वर्चुअल विध्वंसक बनाने की सलाह दी जाती है। लेकिन इस समाधान में दो विशेषताएं हैं।

1. एक विशुद्ध रूप से आभासी विध्वंसक को परिभाषित किया जाना चाहिए। (डिफ़ॉल्ट परिभाषा आमतौर पर "=default" निर्माण का उपयोग करते हुए उपयोग की जाती है।) व्युत्पन्न वर्ग डिस्ट्रक्टर बेस क्लास डिस्ट्रक्टर्स को संपूर्ण विरासत श्रृंखला के साथ कॉल करता है और इसलिए, कतार को रूट तक पहुंचने की गारंटी दी जाती है - एक शुद्ध वर्चुअल डिस्ट्रक्टर।
2. यदि प्रोग्रामर ने व्युत्पन्न वर्ग में एक शुद्ध आभासी विध्वंसक को फिर से परिभाषित नहीं किया है, तो कंपाइलर उसके लिए करेगा (देखें 1.1)। इस प्रकार, एक विशुद्ध रूप से आभासी विध्वंसक के साथ एक अमूर्त वर्ग से लिया गया वर्ग स्पष्ट रूप से विनाशकर्ता को ओवरराइड किए बिना अपनी अमूर्तता खो सकता है।

एक शुद्ध आभासी विध्वंसक का उपयोग करने का एक उदाहरण खंड 4.4 में पाया जा सकता है।

3. इंटरफ़ेस कक्षाएं

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

3.1। कार्यान्वयन

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

इंटरफ़ेस कक्षाओं की अवधारणा का मुख्य बिंदु कार्यान्वयन से इंटरफ़ेस का पूर्ण पृथक्करण है - क्लाइंट केवल इंटरफ़ेस वर्ग के साथ काम करता है, कार्यान्वयन इसके लिए उपलब्ध नहीं है।

3.2। वस्तु निर्माण

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

3.3। वस्तु हटाओ

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

चार मुख्य विकल्प हैं:

1. delete ऑपरेटर का उपयोग करना।
2. एक विशेष आभासी फ़ंक्शन का उपयोग करना।
3. बाहरी फ़ंक्शन का उपयोग करना।
4. स्मार्ट पॉइंटर का उपयोग करके ऑटो डिलीट।

3.3.1। delete ऑपरेटर का उपयोग करना

ऐसा करने के लिए, आपके पास इंटरफ़ेस वर्ग में एक खुला आभासी विध्वंसक होना चाहिए। इस स्थिति में, क्लाइंट के लिए इंटरफ़ेस क्लास के लिए एक पॉइंटर के लिए बुलाया गया delete ऑपरेटर, कार्यान्वयन क्लास के विध्वंसक को कॉल प्रदान करता है। यह विकल्प काम कर सकता है, लेकिन इसे सफल के रूप में पहचानना कठिन है। हमें "बाधा" के विभिन्न पक्षों पर new और delete ऑपरेटरों के कॉल मिलते हैं, कार्यान्वयन पक्ष पर new , ग्राहक पक्ष पर delete । और अगर इंटरफ़ेस वर्ग का कार्यान्वयन एक अलग मॉड्यूल (जो कि काफी सामान्य बात है) में किया जाता है, तो हमें अनुभाग 1.4 से नियम का उल्लंघन मिलता है।

3.3.2। एक विशेष आभासी फ़ंक्शन का उपयोग करना

अधिक प्रगतिशील एक और विकल्प है: इंटरफ़ेस वर्ग में एक विशेष आभासी फ़ंक्शन होना चाहिए जो ऑब्जेक्ट को निकालता है। ऐसा फ़ंक्शन, अंत में, इसे delete this लिए कॉल करने के लिए नीचे आता है, लेकिन कार्यान्वयन पक्ष पर यह पहले से ही हो रहा है। ऐसे फ़ंक्शन को अलग-अलग तरीकों से बुलाया जा सकता है, उदाहरण के लिए, Delete() , लेकिन अन्य विकल्पों का भी उपयोग किया जाता है: Release() , Destroy() , Dispose() , Free() , Close() , आदि। धारा 1.4 में नियम का पालन करने के अलावा, इस विकल्प के कई अतिरिक्त फायदे हैं।

1. आपको क्रियान्वयन वर्ग के लिए उपयोगकर्ता-परिभाषित मेमोरी आवंटन / डीलक्लोलेशन कार्यों का उपयोग करने की अनुमति देता है।
2. आपको कार्यान्वयन ऑब्जेक्ट के जीवनकाल को नियंत्रित करने के लिए एक अधिक जटिल योजना लागू करने की अनुमति देता है, उदाहरण के लिए, एक संदर्भ काउंटर का उपयोग करके।

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

3.3.3। बाहरी फ़ंक्शन का उपयोग करना

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

3.3.4। स्मार्ट पॉइंटर का उपयोग करके ऑटो डिलीट

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

3.4। कार्यान्वयन वर्ग के एक उदाहरण के जीवनकाल के प्रबंधन के लिए अन्य विकल्प

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

3.5। नकल शब्दार्थ

एक इंटरफ़ेस वर्ग के लिए, कॉपी कंस्ट्रक्टर का उपयोग करके कार्यान्वयन ऑब्जेक्ट की प्रतिलिपि बनाना संभव नहीं है, इसलिए यदि कॉपी करना आवश्यक है, तो क्लास में एक वर्चुअल फ़ंक्शन होना चाहिए जो कार्यान्वयन ऑब्जेक्ट की प्रतिलिपि बनाता है और इंटरफ़ेस क्लास के लिए एक पॉइंटर लौटाता है। इस तरह के फ़ंक्शन को अक्सर एक वर्चुअल कंस्ट्रक्टर कहा जाता है, और इसका पारंपरिक नाम Clone() या Duplicate() ।

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

 * = *; 

असाइनमेंट ऑपरेटर को सबसे अच्छा निषिद्ध है, और यदि आवश्यक हो, तो इस तरह के शब्दार्थों के इंटरफ़ेस क्लास में संबंधित वर्चुअल फ़ंक्शन होता है।

असाइनमेंट को प्रतिबंधित करने के दो तरीके हैं।

1. हटाए गए ऑपरेटर को हटाएं ( =delete )। यदि इंटरफ़ेस कक्षाएं एक पदानुक्रम बनाती हैं, तो यह बेस क्लास में करने के लिए पर्याप्त है। इस पद्धति का नुकसान यह है कि यह कार्यान्वयन वर्ग को प्रभावित करता है, प्रतिबंध भी इस पर लागू होता है।
2. डिफ़ॉल्ट परिभाषा ( =default ) के साथ एक संरक्षित असाइनमेंट स्टेटमेंट घोषित करें। यह कार्यान्वयन वर्ग को प्रभावित नहीं करता है, लेकिन इंटरफ़ेस वर्गों के पदानुक्रम के मामले में, प्रत्येक कक्षा में ऐसी घोषणा की जानी चाहिए।

3.6। इंटरफ़ेस वर्ग निर्माता

अक्सर, इंटरफ़ेस वर्ग का निर्माता घोषित नहीं किया जाता है। इस स्थिति में, कंपाइल इनहेरिटेंस को कार्यान्वित करने के लिए आवश्यक डिफ़ॉल्ट कंस्ट्रक्टर को उत्पन्न करता है (देखें खंड 1.1)। यह कंस्ट्रक्टर खुला है, हालांकि सुरक्षित होने के लिए पर्याप्त है। यदि इंटरफ़ेस क्लास में कॉपी करने वाले कंस्ट्रक्टर को डिलीट ( =delete ) घोषित किया जाता है, तो कंस्ट्रक्टर के कंपाइलर द्वारा पीढ़ी को डिफ़ॉल्ट रूप से दबा दिया जाता है, और ऐसे कंस्ट्रक्टर को स्पष्ट रूप से घोषित किया जाना चाहिए। डिफ़ॉल्ट परिभाषा ( =default ) के साथ इसे सुरक्षित बनाना स्वाभाविक है। सिद्धांत रूप में, इस तरह के एक संरक्षित निर्माता की घोषणा हमेशा की जा सकती है। एक उदाहरण खंड 4.4 में है।

3.7। द्विदिश बातचीत

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

3.8। स्मार्ट पॉइंटर्स

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

, , , .

3.9. -

- const. , , -, .

3.10. COM-

COM- , , COM — , COM- , C, , . COM- C++ , COM.

3.11.

(API) (SDK). . -, -, . , (Windows DLL), : -. . , , . LoadLibrary() , -, .

4.

4.1.

, .

 class IBase { protected:    virtual ~IBase() = default; //   public:    virtual void Delete() = 0; //      IBase& operator=(const IBase&) = delete; //   }; 

.

 class IActivatable : public IBase { protected:    ~IActivatable() = default; //   public:    virtual void Activate(bool activate) = 0;    static IActivatable* CreateInstance(); // - }; 

, , . , IBase . , (. 1.3). , .

4.2.

 class Activator : private IActivatable { // ... private:    Activator(); protected:    ~Activator(); public:    void Delete() override;    void Activate(bool activate) override;    friend IActivatable* IActivatable::CreateInstance(); }; Activator::Activator() {/* ... */} Activator::~Activator() {/* ... */} void Activator::Delete() { delete this; } void Activator::Activate(bool activate) {/* ... */} IActivatable* IActivatable::CreateInstance() {    return static_cast<IActivatable*>(new Activator()); } 

, , , - , .

4.3।

4.3.1.

. - ( IBase ):

 struct BaseDeleter {    void operator()(IBase* p) const { p->Delete(); } }; 

std::unique_ptr<> - :

 template <class I> // I —  IBase using UniquePtr = std::unique_ptr<I, BaseDeleter>; 

, , - , UniquePtr .

-:

 template <class I> // I —  - CreateInstance() UniquePtr<I> CreateInstance() {    return UniquePtr<I>(I::CreateInstance()); } 

:

 template <class I> // I —  IBase UniquePtr<I> ToPtr(I* p) {    return UniquePtr<I>(p); } 

std::shared_ptr<> std::unique_ptr<> , , std::shared_ptr<> . Activator .

 auto un1 = CreateInstance<IActivatable>(); un1->Activate(true); auto un2 = ToPtr(IActivatable::CreateInstance()); un2->Activate(true); std::shared_ptr<IActivatable> sh = CreateInstance<IActivatable>(); sh->Activate(true); 

( — -):

 std::shared_ptr<IActivatable> sh2(IActivatable::CreateInstance()); 

std::make_shared<>() , ( ).

: , . : , - . 4.4.

4.3.2.

. -. std::shared_ptr<> , , ( ). std::shared_ptr<> ( ) - , delete . std::shared_ptr<> - ( ) - . .

 #include <memory> class IActivatable; using ActPtr = std::shared_ptr<IActivatable>; //   class IActivatable { protected:    virtual ~IActivatable() = default; //      IActivatable& operator=(const IActivatable&) = default; //   public:    virtual void Activate(bool activate) = 0;    static ActPtr CreateInstance(); // - }; //   class Activator : public IActivatable { // ... public:    Activator();  //      ~Activator(); //      void Activate(bool activate) override; }; Activator::Activator() {/* ... */} Activator::~Activator() {/* ... */} void Activator::Activate(bool activate) {/* ... */} ActPtr IActivatable::CreateInstance() {    return ActPtr(new Activator()); } 

- std::make_shared<>() :

 ActPtr IActivatable::CreateInstance() {    return std::make_shared<Activator>(); } 

std::unique_ptr<> , , - , .

4.4।

C# Java C++ «», . . IBase .

 class IBase { protected:    IBase() = default;    virtual ~IBase() = 0; // ,       virtual void Delete(); //   public:    IBase(const IBase&) = delete;            //      IBase& operator=(const IBase&) = delete; //      struct Deleter        // -    {        void operator()(IBase* p) const { p->Delete(); }    };    friend struct IBase::Deleter; }; 

, Delete() , .

 IBase::~IBase() = default; void IBase::Delete() { delete this; } 

IBase . Delete() , . - IBase . Delete() , - . Delete() , . , 4.3.1.

5. ,

5.1

, , , , .

, , IException Exception .

 class IException {    friend class Exception;    virtual IException* Clone() const = 0;    virtual void Delete() = 0; protected:    virtual ~IException() = default; public:    virtual const char* What() const = 0;    virtual int Code() const = 0;    IException& operator=(const IException&) = delete; }; class Exception {    IException* const m_Ptr; public:    Exception(const char* what, int code);    Exception(const Exception& src) : m_Ptr(src.m_Ptr->Clone()) {}    ~Exception() { m_Ptr->Delete(); }    const IException* Ptr() const { return m_Ptr; } }; 

Exception , IException . , throw , . Exception , . - , .

Exception , , .

IException :

 class ExcImpl : IException {    friend class Exception;    const std::string m_What;    const int m_Code;    ExcImpl(const char* what, int code);    ExcImpl(const ExcImpl&) = default;    IException* Clone() const override;    void Delete() override; protected:    ~ExcImpl() = default; public:    const char* What() const override;    int Code() const override; }; ExcImpl::ExcImpl(const char* what, int code)    : m_What(what), m_Code(code) {} IException* ExcImpl::Clone() const { return new ExcImpl(*this); } void ExcImpl::Delete() { delete this; } const char* ExcImpl::What() const { return m_What.c_str(); } int ExcImpl::Code() const { return m_Code; } 

Exception :

 Exception::Exception(const char* what, int code)    : m_Ptr(new ExcImpl(what, code)) {} 

, — .NET — , — , C++/CLI. , , , C++/CLI.

5.2

- :

 template <typename T> class ICollect { protected:    virtual ~ICollect() = default; public:    virtual ICollect<T>* Clone() const = 0;    virtual void Delete() = 0;    virtual bool IsEmpty() const = 0;    virtual int GetCount() const = 0;    virtual T& GetItem(int ind) = 0;    virtual const T& GetItem(int ind) const = 0;    ICollect<T>& operator=(const ICollect<T>&) = delete; }; 

, -, .

 template <typename T> class ICollect; template <typename T> class Iterator; template <typename T> class Contain {    typedef ICollect<T> CollType;    CollType* m_Coll; public:    typedef T value_type;    Contain(CollType* coll);    ~Contain(); //     Contain(const Contain& src);    Contain& operator=(const Contain& src); //     Contain(Contain&& src);    Contain& operator=(Contain&& src);    bool mpty() const;    int size() const;    T& operator[](int ind);    const T& operator[](int ind) const;    Iterator<T> begin();    Iterator<T> end(); }; 

. , . , , , , - begin() end() , . (. [Josuttis]), for . . , , .

6. -

. -, . . , ++. , .NET, Java Pyton. . , , . .NET Framework C++/CLI C++. .

7.

-, .

.

1. delete .
2. .
3. .

.

, delete . , .

- , . , , delete .

.

, , , , .