👼🏿 🎿 🛑 कांटा न जानने से, पानी में नहीं उतरता। भाग N4 😑 🙎🏻 🤹🏾

इस बार मैं सी ++ में आभासी विरासत के बारे में बात करना चाहता हूं, और इसे बहुत सावधानी से क्यों इस्तेमाल किया जाना चाहिए। पिछले लेख: भाग N1 , N2 , N3
लेख " रेक 2: वर्चुअल इनहेरिटेंस " लेख पर आधारित है। लेख अच्छा है, लेकिन, मेरी राय में, कुछ धुंधला है, और एक शुरुआत पूरी तरह से खतरों का सार समझ नहीं सकती है। मैंने आभासी वंशानुक्रम से जुड़ी समस्याओं के विवरण के अपने संस्करण की पेशकश करने का फैसला किया।

वर्चुअल बेस कक्षाओं के आरंभीकरण के बारे में

शुरुआत में हम इस बारे में बात करेंगे कि अगर कोई वर्चुअल विरासत नहीं है, तो कक्षाएं मेमोरी में कैसे संग्रहीत की जाती हैं। कोड पर विचार करें:

class Base { ... }; class X : public Base { ... }; class Y : public Base { ... }; class XY : public X, public Y { ... };

यहां सब कुछ सरल है। गैर-आभासी आधार वर्ग 'आधार' के सदस्यों को व्युत्पन्न वर्ग के सरल सदस्य डेटा के रूप में होस्ट किया जाता है। परिणामस्वरूप, 'XY' ऑब्जेक्ट के अंदर, हमारे पास दो स्वतंत्र 'बेस' सब -जेक्ट हैं। योजनाबद्ध रूप से, इसे निम्नानुसार दर्शाया जा सकता है:

चित्रा 1. गैर-आभासी कई विरासत।

एक वर्चुअल बेस क्लास ऑब्जेक्ट केवल एक बार एक व्युत्पन्न वर्ग की एक वस्तु में प्रवेश करती है। नीचे दिए गए कोड के लिए 'XY' ऑब्जेक्ट का उपकरण चित्र 2 में दिखाया गया है।

 class Base { ... }; class X : public virtual Base { ... }; class Y : public virtual Base { ... }; class XY : public X, public Y { ... };

चित्रा 2. आभासी कई विरासत।

साझा 'बेस' सबजेक्ट के लिए मेमोरी को 'XY' ऑब्जेक्ट के अंत में आवंटित किए जाने की संभावना है। क्लास को कैसे व्यवस्थित किया जाएगा यह कंपाइलर पर निर्भर करता है। उदाहरण के लिए, एक सामान्य 'बेस' ऑब्जेक्ट के पॉइंटर्स को 'X' और 'Y' कक्षाओं में संग्रहीत किया जा सकता है। लेकिन जैसा कि मैं इसे समझता हूं, यह विधि उपयोग से बाहर हो गई है। अधिक बार, साझा किए गए सबबॉजेक्ट के संदर्भ को ऑफसेट या सूचना के रूप में लागू किया जाता है जो वर्चुअल फ़ंक्शन की तालिका में संग्रहीत होता है।

केवल "सबसे व्युत्पन्न" वर्ग 'XY' को ठीक से पता है कि वर्चुअल बेस क्लास 'बेस' के सब -जेक्ट के लिए मेमोरी कहाँ होनी चाहिए। इसलिए, वर्चुअल बेस कक्षाओं के सभी सबोबिज को आरंभ करने के लिए सबसे व्युत्पन्न वर्ग को सौंपा गया है।

कंस्ट्रक्टर 'XY' सब -जेक्ट 'Base' को इनिशियलाइज़ करते हैं और 'X' और 'Y' में इस ऑब्जेक्ट को इंगित करते हैं। फिर 'X', 'Y', 'XY' कक्षाओं के शेष सदस्यों को आरंभीकृत किया जाता है।

'बेस' सबऑब्जेक्ट को 'XY' कंस्ट्रक्टर में इनिशियलाइज़ करने के बाद, इसे 'X' या 'Y' कंस्ट्रक्टर द्वारा दोबारा इनिशियलाइज़ नहीं किया जाएगा। यह कैसे किया जाएगा यह कंपाइलर पर निर्भर करता है। उदाहरण के लिए, कंपाइलर कंस्ट्रक्टर्स 'X' और 'Y' के लिए एक विशेष अतिरिक्त तर्क दे सकता है, जो क्लास 'Base' को इनिशियलाइज़ नहीं करने का संकेत देगा।

और अब सबसे दिलचस्प, कई गलतफहमियों और गलतियों के लिए अग्रणी। इन निर्माणकर्ताओं पर विचार करें:

 X::X(int A) : Base(A) {} Y::Y(int A) : Base(A) {} XY::XY() : X(3), Y(6) {}

आधार वर्ग निर्माता तर्क के रूप में क्या संख्या लेगा? नंबर 3 या 6? उनमें से एक भी नहीं।

कंस्ट्रक्टर 'XY' वर्चुअल सबबॉजेक्ट 'बेस' को इनिशियलाइज़ करता है, लेकिन क्या यह निहित है। डिफ़ॉल्ट बेस कंस्ट्रक्टर को कहा जाता है।

जब 'XY' कंस्ट्रक्टर 'X' या 'Y' कंस्ट्रक्टर को इनवाइट करता है, तो वह 'Base' को दोबारा इनिशियलाइज़ नहीं करता है। इसलिए, कुछ तर्क के साथ 'आधार' के लिए एक स्पष्ट कॉल नहीं होता है।

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

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

 XY &XY::operator =(const XY &src) { if (this != &src) { X::operator =(*this); Y::operator =(*this); .... } return *this; }

यह कोड 'आधार' ऑब्जेक्ट को डबल कॉपी करेगा। इससे बचने के लिए, 'X' और 'Y' वर्गों में फ़ंक्शंस लागू करना आवश्यक है जो 'Base' वर्ग के सदस्य कॉपी नहीं करेंगे। 'आधार' वर्ग की सामग्री को यहां एक बार कॉपी किया जाता है। सही किया गया कोड:

 XY &XY::operator =(const XY &src) { if (this != &src) { Base::operator =(*this); X::PartialAssign(*this); Y::PartialAssign(*this); .... } return *this; }

ऐसा कोड काम करेगा, लेकिन यह सब बदसूरत और भ्रमित करने वाला है। इसलिए, यह कहा जाता है कि कई आभासी विरासत से बचना बेहतर है।

वर्चुअल बेस क्लास और टाइप कास्टिंग

वर्चुअल बेस क्लासेस को मेमोरी में रखने की ख़ासियत के कारण, कोई भी इन प्रकार के रूपांतरण नहीं कर सकता है:

 Base *b = Get(); XY *q = static_cast<XY *>(b); //   XY *w = (XY *)(b); //

हालाँकि, एक लगातार प्रोग्रामर अभी भी 'reinterpret_cast' ऑपरेटर का उपयोग करके टाइप कर सकता है:

 XY *e = reinterpret_cast<XY *>(b);

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

प्रकार रूपांतरण करने का एकमात्र तरीका डायनेमिक_कास्ट ऑपरेटर का उपयोग करना है। हालांकि, कोड जहां डायनामिक_कास्ट नियमित रूप से उपयोग किया जाता है, बदबू आती है।

चित्रा 3. टाइप कास्टिंग।

क्या आभासी विरासत को छोड़ दिया जाना चाहिए?

मैं कई लेखकों से सहमत हूं कि आभासी विरासत को हर तरह से बचा जाना चाहिए। और सरल से कई विरासत भी छोड़ना बेहतर है।

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

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

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

एकाधिक वंशानुक्रम के लाभ

खैर, कई आभासी विरासत और सिर्फ कई विरासत की आलोचना समझ में आती है। क्या ऐसी जगहें हैं जहां यह सुरक्षित और सुविधाजनक है।

हां, मैं कम से कम एक चीज का नाम दे सकता हूं: इंटरफेस को मिला देना। यदि यह पद्धति आपके लिए परिचित नहीं है, तो मैं पुस्तक "पर्याप्त लंबाई की एक रस्सी ... पैर में खुद को गोली मारता हूं" [3] की ओर मुड़ने का प्रस्ताव करता हूं।

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

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

आगे पढ़ रहे हैं

स्टीफन सी। देहुरस्ट। फिसलन स्थानों सी ++। अपने कार्यक्रमों को डिजाइन और संकलित करते समय समस्याओं से कैसे बचें। - एम .: डीएमके प्रेस। - 264 पी .: बीमार। बीबीके 32.973.26-018.2, आईएसबीएन 978-5-94074-837-3। (देखें टिप 45 और 53 की संख्या)।
विकिपीडिया। एकत्रीकरण (प्रोग्रामिंग) ।
एलेन आई। गोलूब। "पर्याप्त लंबाई की एक रस्सी ... पैर में ही गोली मार।" (इंटरनेट पर आसानी से खोजा गया। खंड 101 देखें।)

कांटा न जानने से, पानी में नहीं उतरता। भाग N4

वर्चुअल बेस कक्षाओं के आरंभीकरण के बारे में

वर्चुअल बेस क्लास और टाइप कास्टिंग

क्या आभासी विरासत को छोड़ दिया जाना चाहिए?

एकाधिक वंशानुक्रम के लाभ

आगे पढ़ रहे हैं

More articles: