C ++ vtables। भाग 2 (वर्चुअल इनहेरिटेंस + कंपाइलर-जनरेटेड कोड)

लेख का अनुवाद विशेष रूप से पाठ्यक्रम "C ++ डेवलपर" के छात्रों के लिए तैयार किया गया था। क्या इस दिशा में विकास करना दिलचस्प है? Google टेस्ट फ्रेमवर्क प्रैक्टिस क्लास की रिकॉर्डिंग देखें!

भाग 3 - वर्चुअल इनहेरिटेंस

इस लेख के पहले और दूसरे भाग में , हमने बात की कि कैसे vtables सबसे सरल मामलों में काम करते हैं, और फिर कई उत्तराधिकार में। वर्चुअल इनहेरिटेंस स्थिति को और अधिक जटिल बना देता है।

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

class ios ... class istream : virtual public ios ... class ostream : virtual public ios ... class iostream : public istream, public ostream 

यदि यह ऊपर दिए गए virtual कीवर्ड के लिए नहीं था, तो iostream वास्तव में ios दो उदाहरण होंगे जो सिंक्रोनाइज़ेशन के दौरान सिरदर्द पैदा कर सकते हैं और बस अप्रभावी होंगे।

वर्चुअल इनहेरिटेंस को समझने के लिए, हम निम्नलिखित कोड टुकड़े पर विचार करेंगे:

 #include <iostream> using namespace std; class Grandparent { public: virtual void grandparent_foo() {} int grandparent_data; }; class Parent1 : virtual public Grandparent { public: virtual void parent1_foo() {} int parent1_data; }; class Parent2 : virtual public Grandparent { public: virtual void parent2_foo() {} int parent2_data; }; class Child : public Parent1, public Parent2 { public: virtual void child_foo() {} int child_data; }; int main() { Child child; } 

आइए child का पता लगाएं। मैं बड़ी मात्रा में मेमोरी को डंप करके शुरू करूंगा, जहां पर vtable Child शुरू होता है, जैसा कि हमने पिछले भागों में किया था, और फिर परिणामों का विश्लेषण किया। मेरा सुझाव है कि यहां परिणाम पर एक त्वरित नज़र डालें और जब मैं नीचे दिए गए विवरणों का खुलासा करता हूं तो यह वापस लौटता है।

 (gdb) p child $1 = {<Parent1> = {<Grandparent> = {_vptr$Grandparent = 0x400998 <vtable for Child+96>, grandparent_data = 0}, _vptr$Parent1 = 0x400950 <vtable for Child+24>, parent1_data = 0}, <Parent2> = {_vptr$Parent2 = 0x400978 <vtable for Child+64>, parent2_data = 4195888}, child_data = 0} (gdb) x/600xb 0x400938 0x400938 <vtable for Child>: 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400940 <vtable for Child+8>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400948 <vtable for Child+16>: 0x00 0x0b 0x40 0x00 0x00 0x00 0x00 0x00 0x400950 <vtable for Child+24>: 0x70 0x08 0x40 0x00 0x00 0x00 0x00 0x00 0x400958 <vtable for Child+32>: 0xa0 0x08 0x40 0x00 0x00 0x00 0x00 0x00 0x400960 <vtable for Child+40>: 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400968 <vtable for Child+48>: 0xf0 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x400970 <vtable for Child+56>: 0x00 0x0b 0x40 0x00 0x00 0x00 0x00 0x00 0x400978 <vtable for Child+64>: 0x90 0x08 0x40 0x00 0x00 0x00 0x00 0x00 0x400980 <vtable for Child+72>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400988 <vtable for Child+80>: 0xe0 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x400990 <vtable for Child+88>: 0x00 0x0b 0x40 0x00 0x00 0x00 0x00 0x00 0x400998 <vtable for Child+96>: 0x80 0x08 0x40 0x00 0x00 0x00 0x00 0x00 0x4009a0 <VTT for Child>: 0x50 0x09 0x40 0x00 0x00 0x00 0x00 0x00 0x4009a8 <VTT for Child+8>: 0xf8 0x09 0x40 0x00 0x00 0x00 0x00 0x00 0x4009b0 <VTT for Child+16>: 0x18 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x4009b8 <VTT for Child+24>: 0x98 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x4009c0 <VTT for Child+32>: 0xb8 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x4009c8 <VTT for Child+40>: 0x98 0x09 0x40 0x00 0x00 0x00 0x00 0x00 0x4009d0 <VTT for Child+48>: 0x78 0x09 0x40 0x00 0x00 0x00 0x00 0x00 0x4009d8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x4009e0 <construction vtable for Parent1-in-Child>: 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x4009e8 <construction vtable for Parent1-in-Child+8>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x4009f0 <construction vtable for Parent1-in-Child+16>: 0x50 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x4009f8 <construction vtable for Parent1-in-Child+24>: 0x70 0x08 0x40 0x00 0x00 0x00 0x00 0x00 0x400a00 <construction vtable for Parent1-in-Child+32>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400a08 <construction vtable for Parent1-in-Child+40>: 0xe0 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x400a10 <construction vtable for Parent1-in-Child+48>: 0x50 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400a18 <construction vtable for Parent1-in-Child+56>: 0x80 0x08 0x40 0x00 0x00 0x00 0x00 0x00 0x400a20 <typeinfo name for Parent1>: 0x37 0x50 0x61 0x72 0x65 0x6e 0x74 0x31 0x400a28 <typeinfo name for Parent1+8>: 0x00 0x31 0x31 0x47 0x72 0x61 0x6e 0x64 0x400a30 <typeinfo name for Grandparent+7>: 0x70 0x61 0x72 0x65 0x6e 0x74 0x00 0x00 0x400a38 <typeinfo for Grandparent>: 0x50 0x10 0x60 0x00 0x00 0x00 0x00 0x00 0x400a40 <typeinfo for Grandparent+8>: 0x29 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400a48: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400a50 <typeinfo for Parent1>: 0xa0 0x10 0x60 0x00 0x00 0x00 0x00 0x00 0x400a58 <typeinfo for Parent1+8>: 0x20 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400a60 <typeinfo for Parent1+16>: 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x400a68 <typeinfo for Parent1+24>: 0x38 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400a70 <typeinfo for Parent1+32>: 0x03 0xe8 0xff 0xff 0xff 0xff 0xff 0xff 0x400a78: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400a80 <construction vtable for Parent2-in-Child>: 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400a88 <construction vtable for Parent2-in-Child+8>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400a90 <construction vtable for Parent2-in-Child+16>: 0xd0 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400a98 <construction vtable for Parent2-in-Child+24>: 0x90 0x08 0x40 0x00 0x00 0x00 0x00 0x00 0x400aa0 <construction vtable for Parent2-in-Child+32>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400aa8 <construction vtable for Parent2-in-Child+40>: 0xf0 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x400ab0 <construction vtable for Parent2-in-Child+48>: 0xd0 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400ab8 <construction vtable for Parent2-in-Child+56>: 0x80 0x08 0x40 0x00 0x00 0x00 0x00 0x00 0x400ac0 <typeinfo name for Parent2>: 0x37 0x50 0x61 0x72 0x65 0x6e 0x74 0x32 0x400ac8 <typeinfo name for Parent2+8>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400ad0 <typeinfo for Parent2>: 0xa0 0x10 0x60 0x00 0x00 0x00 0x00 0x00 0x400ad8 <typeinfo for Parent2+8>: 0xc0 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400ae0 <typeinfo for Parent2+16>: 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x400ae8 <typeinfo for Parent2+24>: 0x38 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400af0 <typeinfo for Parent2+32>: 0x03 0xe8 0xff 0xff 0xff 0xff 0xff 0xff 0x400af8 <typeinfo name for Child>: 0x35 0x43 0x68 0x69 0x6c 0x64 0x00 0x00 0x400b00 <typeinfo for Child>: 0xa0 0x10 0x60 0x00 0x00 0x00 0x00 0x00 0x400b08 <typeinfo for Child+8>: 0xf8 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400b10 <typeinfo for Child+16>: 0x02 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x400b18 <typeinfo for Child+24>: 0x50 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400b20 <typeinfo for Child+32>: 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400b28 <typeinfo for Child+40>: 0xd0 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400b30 <typeinfo for Child+48>: 0x02 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x400b38 <vtable for Grandparent>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x400b40 <vtable for Grandparent+8>: 0x38 0x0a 0x40 0x00 0x00 0x00 0x00 0x00 0x400b48 <vtable for Grandparent+16>: 0x80 0x08 0x40 0x00 0x00 0x00 0x00 0x00 

वाह, बहुत सारी जानकारी है। दो नए प्रश्न तुरंत VTT : VTT क्या है और vtable for X-in-Child निर्माण vtable for X-in-Child ? हम उन्हें जल्द ही जवाब देंगे।
बच्चे स्मृति संरचना के साथ शुरू करते हैं:

दरअसल, Child पास Child का केवल 1 उदाहरण है। निर्विवाद बात यह है कि वह स्मृति में अंतिम है, हालांकि वह पदानुक्रम में सर्वोच्च है।
यहाँ vtable संरचना है:

ऊपर एक नई अवधारणा है - virtual-base offset । जल्द ही हम समझ जाएंगे कि वह वहां क्या कर रहा है।
अगला, आइए इन अजीब दिखने वाले construction vtables । यहाँ vtable for Parent1-in-Child निर्माण vtable for Parent1-in-Child :

फिलहाल, मुझे लगता है कि आप पर यादृच्छिक संख्याओं के साथ अधिक तालिकाओं को ढेर करने की तुलना में इस प्रक्रिया का वर्णन करना अधिक समझ में आएगा। तो:

कल्पना कीजिए कि आप एक Child । आपको स्मृति के एक नए टुकड़े में खुद का निर्माण करने के लिए कहा जाता है। चूँकि आप सीधे Grandparent प्राप्त करते हैं (जो कि वर्चुअल इनहेरिटेंस का मतलब है), आप सबसे पहले सीधे इसके कंस्ट्रक्टर को कॉल करेंगे (यदि यह वर्चुअल इनहेरिटेंस नहीं थे, तो आप कंस्ट्रक्टर Parent1 1 को कॉल करेंगे, जो बदले में Parent1 कंस्ट्रक्टर Parent1 )। आपने this += 32 बाइट सेट किया है, क्योंकि यह वह जगह है जहां Grandparent डेटा स्थित है, और आप कंस्ट्रक्टर को कॉल करते हैं। बहुत सरल है।

तो यह Parent1 बनाने का समय है। Parent1 सुरक्षित रूप से यह मान सकता है कि जब तक वह खुद का निर्माण करता है, तब तक Parent1 निर्माण पहले ही हो चुका होता है, इसलिए वह उदाहरण के लिए, Grandparent डेटा और विधियों तक पहुंच प्राप्त कर सकता है। लेकिन रुकिए, वह कैसे जान सकता है कि यह डेटा कहां मिलेगा? वे चर Parent1 साथ एक ही स्थान पर नहीं हैं!

construction table for Parent1-in-Child दृश्य में प्रवेश करती है। यह तालिका Parent1 को बताने के लिए है कि डेटा के टुकड़े कहां से प्राप्त किए जा सकते हैं। this Parent1 के डेटा को Parent1 । virtual-base offset इंगित करता है कि आप ग्रैंडपेरेंट डेटा कहां पा सकते हैं: स्टेप 32 बाइट्स इससे आगे हैं और आपको Grandparent मेमोरी मिलेगी। क्या आप इसे प्राप्त करते हैं? वर्चुअल-बेस ऑफसेट top_offset के समान है, लेकिन वर्चुअल कक्षाओं के लिए।

अब जब हम इसे समझते हैं, मूल रूप से Parent2 का निर्माण समान है, केवल construction table for Parent2-in-Child का उपयोग कर रहा है। दरअसल, Parent2-in-Child में 16 बाइट्स की virtual-base offset है।

जानकारी को थोड़ा सोखने दें। क्या आप जारी रखने के लिए तैयार हैं? सब ठीक है।
अब VTT वापस आते हैं। यहां VTT संरचना है:

VTT virtual-table table के लिए खड़ा है, जिसका अर्थ है कि यह एक व्यवहार्य है। यह एक अनुवाद तालिका है जो जानता है, उदाहरण के लिए, क्या कंस्ट्रक्टर Parent1 सिंगल ऑब्जेक्ट के लिए, Parent1-in-Child या Parent1-in-SomeOtherObject । यह हमेशा दिखाई देने के तुरंत बाद दिखाई देता है, ताकि संकलक को पता चल जाए कि उसे कहां खोजना है। इसलिए, वस्तुओं में स्वयं एक और सूचक को संग्रहीत करने की आवश्यकता नहीं है।

फूह ... बहुत सारी जानकारी, लेकिन मुझे लगता है कि हमने वह सब कुछ कवर किया, जिसे मैं कवर करना चाहता था। चौथे भाग में हम उच्च स्तर के vtables के विवरण के बारे में बात करेंगे। छोड़ें नहीं, क्योंकि यह शायद इस लेख का सबसे महत्वपूर्ण हिस्सा है!

भाग 4 - संकलक द्वारा उत्पन्न कोड

इस लेख में इस बिंदु पर, हमने सीखा कि कैसे vtables और typeinfo हमारे बायनेरिज़ में फिट होती हैं और कंपाइलर उनका उपयोग कैसे करते हैं। अब हम उस काम के हिस्से को समझेंगे जो कंपाइलर हमारे लिए स्वचालित रूप से करता है।

कंस्ट्रक्टर्स

किसी भी वर्ग के निर्माता के लिए, निम्न कोड उत्पन्न होता है:

• अभिभावक निर्माण को बुलाते हैं, यदि कोई हो;
• व्यवहार्य बिंदुओं की स्थापना, यदि कोई हो;
• इनिशियलाइज़र्स की सूची के अनुसार सदस्यों का प्रारंभिककरण;
• कंस्ट्रक्टर ब्रैकेट के अंदर कोड निष्पादन।

उपरोक्त सभी एक स्पष्ट कोड के बिना हो सकते हैं:

• जब तक अन्यथा निर्दिष्ट नहीं किया जाता है, तब तक मूल निर्माणकर्ता डिफ़ॉल्ट रूप से स्वतः प्रारंभ हो जाते हैं;
• सदस्य डिफ़ॉल्ट रूप से आरंभिक होते हैं यदि उनके पास प्रारंभिक सूची में डिफ़ॉल्ट मान या प्रविष्टियाँ नहीं होती हैं;
• पूरे निर्माणकर्ता को चिह्नित किया जा सकता है = डिफ़ॉल्ट;
• केवल व्यवहार्य असाइनमेंट हमेशा छिपा होता है।

यहाँ एक उदाहरण है:

 #include <iostream> #include <string> using namespace std; class Parent { public: Parent() { Foo(); } virtual ~Parent() = default; virtual void Foo() { cout << "Parent" << endl; } int i = 0; }; class Child : public Parent { public: Child() : j(1) { Foo(); } void Foo() override { cout << "Child" << endl; } int j; }; class Grandchild : public Child { public: Grandchild() { Foo(); s = "hello"; } void Foo() override { cout << "Grandchild" << endl; } string s; }; int main() { Grandchild g; } 

आइए प्रत्येक वर्ग के निर्माता के लिए एक छद्म कोड लिखें:

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

 Parent Child Grandchild 

शुद्ध आभासी कार्यों के बारे में क्या? यदि उन्हें लागू नहीं किया जाता है (हाँ, तो आप विशुद्ध रूप से आभासी कार्यों को लागू कर सकते हैं, लेकिन आपको इसकी आवश्यकता क्यों है?), आप शायद (और उम्मीद है) सीधे segfault पर जाएंगे। कुछ संकलक त्रुटि की उपेक्षा करते हैं, जो शांत है।

विनाशकर्ता

जैसा कि आप कल्पना कर सकते हैं, विध्वंसक उसी तरह से व्यवहार करते हैं जैसे कि निर्माणकर्ता, केवल रिवर्स ऑर्डर में।

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

इम्प्लिमेंट कास्ट

जैसा कि हमने दूसरे और तीसरे भाग में देखा है, एक बच्चे के ऑब्जेक्ट के लिए एक पॉइंटर जरूरी नहीं कि एक ही उदाहरण के पेरेंट पॉइंटर के समान हो (जैसा कि कई उत्तराधिकार के मामले में)।

हालाँकि, आपके (डेवलपर) के लिए, एक फ़ंक्शन को कॉल करने के लिए कोई अतिरिक्त काम नहीं है जो एक माता-पिता सूचक प्राप्त करता है। ऐसा इसलिए है क्योंकि कंपाइलर अंतर्निहित रूप से this स्थानांतरित कर देता है जब आप अभिभावकों की कक्षाओं के संदर्भ और संदर्भ जोड़ते हैं।

डायनामिक कास्ट (RTTI)

डायनेमिक कास्ट typeinfo टेबल का उपयोग typeinfo , जिसकी हमने पहले भाग में जांच की थी। वे रन टाइम पर ऐसा करते हैं, typeinfo लिए typeinfo एंट्री एक पॉइंटर को देखते हैं, इससे पहले कि typeinfo पॉइंटर किस ओर typeinfo करता है, और अगर कास्ट संभव है, तो यह जांचने के लिए वहां से क्लास का उपयोग करें।

यह अक्सर उपयोग किए जाने पर डायनेमिक_कास्ट की लागत की व्याख्या करता है।

विधि संकेत

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

 // TODO:  ,     

अपने आप को जांचें!

अब आप अपने आप को समझा सकते हैं कि निम्न कोड टुकड़ा ऐसा क्यों व्यवहार करता है:

 #include <iostream> using namespace std; class FooInterface { public: virtual ~FooInterface() = default; virtual void Foo() = 0; }; class BarInterface { public: virtual ~BarInterface() = default; virtual void Bar() = 0; }; class Concrete : public FooInterface, public BarInterface { public: void Foo() override { cout << "Foo()" << endl; } void Bar() override { cout << "Bar()" << endl; } }; int main() { Concrete c; c.Foo(); c.Bar(); FooInterface* foo = &c; foo->Foo(); BarInterface* bar = (BarInterface*)(foo); bar->Bar(); //  "Foo()" - WTF? } 

यह मेरे चार-भाग के लेख को समाप्त करता है। मुझे उम्मीद है कि आप मेरी तरह कुछ नया सीखेंगे।