वर्चुअल टेबल टेबल क्या है?

एक बार स्लैक में, मैं अपनी C ++ की संक्षिप्त शब्दावली के लिए एक नए संक्षिप्त विवरण के साथ आया: "VTT।" गॉडबोल्ट :

test.o: In function `MyClass': test.cc:3: undefined reference to `VTT for MyClass' 

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

गैर-आभासी विरासत के लिए डिज़ाइन ऑर्डर

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

इस तरह:

 struct A {}; struct B : A {}; struct C {}; struct D : C {}; struct E : B, D {}; //     // ABCDE 

वर्चुअल बेस कक्षाओं के लिए डिज़ाइन ऑर्डर

लेकिन आभासी विरासत सभी कार्डों को भ्रमित करती है! वर्चुअल इनहेरिटेंस के साथ, हमारे पास हीरे के आकार की पदानुक्रम हो सकती है जिसमें दो अलग-अलग मूल अभिभावक एक साझा पूर्वज साझा कर सकते हैं।

 struct G {}; struct M : virtual G {}; struct F : virtual G {}; struct E : M, F {}; //     // GMFE 

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

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

पिछले खंड और निम्न उदाहरण से हमारे ABCDE उदाहरण के बीच अंतर पर विचार करें:

 struct A {}; struct B : virtual A {}; struct C {}; struct D : virtual C {}; struct E : B, D {}; //     // ACBDE 

पूर्ण ऑब्जेक्ट E का निर्माता पहले वर्चुअल सबऑब्जेक्ट्स A और C के बेस ऑब्जेक्ट के कंस्ट्रक्टर्स को कॉल करता है; तब आधार गैर-आभासी विरासत वस्तु B और D के निर्माता कहलाते हैं। B और D क्रमशः A और C के निर्माण के लिए जिम्मेदार नहीं हैं।

डिज़ाइन करने योग्य टेबल

मान लीजिए कि हमारे पास कुछ आभासी तरीकों के साथ एक वर्ग है, उदाहरण के लिए, जैसे ( गॉडबोलेट )

 struct Cat { Cat() { poke(); } virtual void poke() { puts("meow"); } }; struct Lion : Cat { std::string roar = "roar"; Lion() { poke(); } void poke() override { roar += '!'; puts(roar.c_str()); } }; 

जब हम लायन का निर्माण करते हैं, तो हम बेसिक कैट सब -जेक्ट का निर्माण शुरू करते हैं। कैट का निर्माता प्रहार () कहता है। इस बिंदु पर, हमारे पास केवल एक कैट ऑब्जेक्ट है - हमने अभी तक सदस्य डेटा को इनिशियलाइज़ नहीं किया है जो कि लायन ऑब्जेक्ट बनाने के लिए आवश्यक है। यदि कैट कंस्ट्रक्टर लायन :: पोक () को कॉल करता है, तो यह std :: string roar के अनरिटलाइज्ड मेंबर को बदलने की कोशिश कर सकता है और हमें UB मिलता है। तो, C ++ मानक हमें बिल्ली निर्माता में ऐसा करने के लिए बाध्य करता है, पोक को कॉल करना () वर्चुअल विधि को कैट :: पोक (), न कि शेर :: पोक () कहना चाहिए!

कोई समस्या नहीं है। कंपाइलर केवल कैट :: कैट () (बेस ऑब्जेक्ट के लिए संस्करण और पूर्ण ऑब्जेक्ट के लिए संस्करण दोनों) का उद्देश्य कैट ऑब्जेक्ट के वाइबर को सेट करके प्रारंभ करता है। शेर :: शेर () बिल्ली को बुलाएगा: बिल्ली (), और फिर कोष्ठक में कोड चलाने से पहले शेर के अंदर बिल्ली वस्तु के लिए सूचक तालिका के लिए vptr रीसेट करें। कोई बात नहीं!

वर्चुअल इनहेरिटेंस ऑफ़सेट्स

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

 struct Animal { const char *data = "hi"; }; struct Cat : virtual Animal { Cat() { puts(data); } }; struct Nermal : Cat {}; struct Garfield : Cat { int padding; }; 

बिल्ली निर्माता सदस्य :: पशु डेटा पर सवाल उठाता है। यदि यह कैट ऑब्जेक्ट नर्मल ऑब्जेक्ट का आधार सबबॉजेक्ट है, तो इसका सदस्य डेटा vptr के ठीक पीछे ऑफसेट 8 पर है। लेकिन अगर कैट ऑब्जेक्ट गारफील्ड ऑब्जेक्ट का अंतर्निहित उप-खंड है, तो सदस्य डेटा vptr और गारफील्ड :: पैडिंग के पीछे, ऑफसेट 16 पर है। सामना करने के लिए, इटेनियम एबीआई बिल्ली वस्तु के व्यवहार में आभासी आधार वस्तुओं के ऑफसेट को संग्रहीत करता है। कैट-इन-निर्मल के लिए वाइबेट इस तथ्य को संरक्षित करता है कि पशु, अंतर्निहित कैट सबबॉजेक्ट, ऑफसेट 8 पर संग्रहीत है; कैट-इन-गारफील्ड के लिए व्यवहार्य इस तथ्य को बरकरार रखता है कि पशु, अंतर्निहित कैट सबबजेक्ट, को ऑफसेट 16 पर संग्रहीत किया जाता है।

अब इसे पिछले भाग से मिलाएँ। संकलक को यह सुनिश्चित करना चाहिए कि कैट :: कैट () (बेस ऑब्जेक्ट संस्करण और पूर्ण ऑब्जेक्ट संस्करण दोनों) कैट-इन-निर्मल के लिए वीआईबीटीआर पर शुरू होता है या कैट-इन-गारफील्ड के लिए व्यवहार्यता पर टाइप के आधार पर स्थापित होता है सबसे व्युत्पन्न सुविधा! लेकिन यह कैसे काम करता है?

सबसे व्युत्पन्न वस्तु के लिए पूर्ण वस्तु का निर्माण करने वाले को पूर्व-गणना करना चाहिए कि किस तालिका में वह वस्तु के निर्माण के समय संदर्भ के लिए आधार उपपट्ट का vptr चाहता है, और फिर सबसे व्युत्पन्न वस्तु के लिए पूर्ण वस्तु का निर्माण करने वाले को आधार उप-आधार के आधार वस्तु के निर्माणकर्ता को यह जानकारी देनी होगी। एक छिपे हुए पैरामीटर के रूप में! आइए कैट: कैट () ( गॉडबॉल्ट ) के लिए उत्पन्न कोड को देखें:

 _ZN3CatC1Ev: #    Cat movq $_ZTV3Cat+24, (%rdi) # this->vptr = &vtable-for-Cat; retq _ZN3CatC2Ev: #     Cat movq (%rsi), %rax # fetch a value from rsi movq %rax, (%rdi) # this->vptr = *rsi; retq 

बेस ऑब्जेक्ट का निर्माता% rdi में न केवल इस छिपे हुए पैरामीटर को स्वीकार करता है, बल्कि% rsi में छिपे हुए VTT पैरामीटर को भी स्वीकार करता है! बेस ऑब्जेक्ट कंस्ट्रक्टर (% rsi) से पते को लोड करता है और कैट ऑब्जेक्ट की व्यवहार्यता में पते को संग्रहीत करता है।

जिसे कोई भी आधार का निर्माता कहता है, कैट ऑब्जेक्ट का अनुमान लगाने के लिए जिम्मेदार है कि बिल्ली :: बिल्ली () पता vptr में लिखा जाना चाहिए और उस पते में सूचक को (% rsi) सेट करने के लिए।

हमें दूसरे स्तर की पहचान की आवश्यकता क्यों है?

पूर्ण नर्मल वस्तु के निर्माता पर विचार करें।

 _ZN3CatC2Ev: #    Cat movq (%rsi), %rax #    rsi movq %rax, (%rdi) # this->vptr = *rsi; retq _ZN6NermalC1Ev: #    Nermal pushq %rbx movq %rdi, %rbx movl $_ZTT6Nermal+8, %esi # %rsi = &VTT-for-Nermal callq _ZN3CatC2Ev #     Cat movq $_ZTV6Nermal+24, (%rbx) # this->vptr = &vtable-for-Nermal popq %rbx retq _ZTT6Nermal: .quad _ZTV6Nermal+24 # vtable-for-Nermal .quad _ZTC6Nermal0_3Cat+24 # construction-vtable-for-Cat-in-Nermal 

क्यों _ZTC6Nermal0_3Cat + 24 डेटा अनुभाग में स्थित है और इसका पता% rsi को दिया गया है, बजाय सीधे _ZTC6Nermal0_3Cat + 24 को पारित किए सीधे?

 #   ? _ZN3CatC2Ev: #     Cat movq %rsi, (%rdi) # this->vptr = rsi; retq _ZN6NermalC1Ev: #     Nermal pushq %rbx movq %rdi, %rbx movl $_ZTC6Nermal0_3Cat+24, %esi # %rsi = &construction-vtable-for-Cat-in-Nermal callq _ZN3CatC2Ev #     Cat movq $_ZTV6Nermal+24, (%rbx) # this->vptr = &vtable-for-Nermal popq %rbx retq 

ऐसा इसलिए है क्योंकि हमारे पास विरासत के कई स्तर हो सकते हैं! वंशानुक्रम के प्रत्येक स्तर पर, बेस ऑब्जेक्ट के निर्माता को वीपीटीआर सेट करना चाहिए और फिर, संभवतः, अगले बेस कंस्ट्रक्टर के लिए श्रृंखला को नियंत्रित करें, जो कुछ अन्य मानों के लिए वीपीटी सेट कर सकता है। यह एक सूची या संकेत की एक तालिका का अर्थ है।

यहाँ एक ठोस उदाहरण ( गॉडबोल्ट ) दिया गया है:

 struct VB { int member_of_vb = 42; }; struct Grandparent : virtual VB { Grandparent() {} }; struct Parent : Grandparent { Parent() {} }; struct Gretel : Parent { Gretel() : VB{1000} {} }; struct Hansel : Parent { int padding; Hansel() : VB{2000} {} }; 

द ग्रैंडपेरेंट बेस कंस्ट्रक्टर ऑब्जेक्ट को ग्रैंडपरेंट के लिए अपना वीटीआर सेट करना होगा - कुछ और, जो सबसे व्युत्पन्न वर्ग है। पेरेंट बेस ऑब्जेक्ट के कंस्ट्रक्टर को पहले Grandparent :: Grandparent () को उपयुक्त% rsi के साथ कॉल करना होगा, और फिर पेरेंट को vptr सेट करना होगा - कुछ और, जो कि सबसे अधिक व्युत्पन्न वर्ग है। Gretel के लिए इसे लागू करने का एक तरीका:

 Gretel::Gretel() [  ]: pushq %rbx movq %rdi, %rbx movl $1000, 8(%rdi) # imm = 0x3E8 movl $VTT for Gretel+8, %esi callq Parent::Parent() [  ] movq $vtable for Gretel+24, (%rbx) popq %rbx retq VTT for Gretel: .quad vtable for Gretel+24 .quad construction vtable for Parent-in-Gretel+24 .quad construction vtable for Grandparent-in-Gretel+24 

आप Godbolt में देख सकते हैं कि पेरेंट क्लास के बेस ऑब्जेक्ट का कंस्ट्रक्टर पहले Grandparent :: Grandparent () को% rsi + 8 कहता है, फिर अपना vptr to (% rsi) सेट करता है। इसलिए, यहां हम इस तथ्य का उपयोग कर रहे हैं कि ग्रेटेल, इसलिए बोलने के लिए, ध्यान से ब्रेडक्रंब का एक रास्ता तैयार किया गया था जिसके निर्माण के दौरान उसके सभी आधार वर्गों का पालन किया गया था।

उसी VTT का उपयोग विध्वंसक ( गॉडबोल्ट ) में किया जाता है। जहाँ तक मुझे पता है, VTT टेबल की अशक्त पंक्ति का उपयोग कभी नहीं किया जाता है। Gretel कंस्ट्रक्टर Vretr में Gretel + 24 के लिए व्यवहार्य लोड करता है, लेकिन वह जानता है कि यह पता स्थिर है, इसे कभी भी VTT से लोड करने की आवश्यकता नहीं है। मुझे लगता है कि मेज की शून्य पंक्ति को केवल ऐतिहासिक कारणों से संरक्षित किया गया था। (और निश्चित रूप से, कंपाइलर इसे दूर नहीं फेंक सकता है, क्योंकि यह इटेनियम एबीआई का उल्लंघन होगा और इटेनियम-एबीआई का पालन करने वाले पुराने कोड से लिंक करना असंभव होगा)।

यह सब है, हम आभासी तालिकाओं, या VTT की एक मेज पर देखा।

आगे की जानकारी

आप इन स्थानों में VTT जानकारी पा सकते हैं:

StackOverflow: “ एक वर्ग के लिए VTT क्या है? "
" जीसीसी सी ++ कंपाइलर v4.0.1 में कई विरासत पर VTable नोट्स " (मॉर्गन डिटेक्टर, 2005)
इटेनियम सी ++ एबीआई , "वीटीटी ऑर्डर" अनुभाग

अंत में, मुझे यह दोहराना है कि VTT Itanium C ++ ABI की एक विशेषता है, और इसका उपयोग लिनक्स, OSX, आदि पर किया जाता है। Windows पर उपयोग किए जाने वाले MSVC ABI में VTT नहीं है, और वर्चुअल इनहेरिटेंस के लिए एक पूरी तरह से अलग तंत्र का उपयोग करता है। मैं (अभी तक) MSVC ABI के बारे में लगभग कुछ भी नहीं जानता, लेकिन शायद एक दिन मुझे सब कुछ पता चल जाएगा और इसके बारे में एक पोस्ट लिखूंगा!