हेडर में परिभाषित सी ++ वर्चुअल फ़ंक्शन को संकलित और vtable में लिंक क्यों नहीं किया जा सकता है?

Question

स्थिति निम्न है। मैं पुस्तकालय साझा किया है, जो वर्ग परिभाषा शामिल हैं -

QueueClass : IClassInterface 
{ 
    virtual void LOL() { do some magic} 
} 

मेरे साझा लाइब्रेरी प्रारंभ वर्ग के सदस्य

QueueClass *globalMember = new QueueClass(); 

मेरे शेयर पुस्तकालय निर्यात सी समारोह जो globalMember सूचक रिटर्न -

void * getGlobalMember(void) { return globalMember;} 

मेरे एप्लिकेशन ग्लोबल मेम्बर का उपयोग करता है जैसे

((IClassInterface*)getGlobalMember())->LOL(); 

अब बहुत उबेर सामान - यदि मैं साझा लाइब्रेरी से एलओएल का संदर्भ नहीं देता हूं, तो एलओएल लिंक नहीं है और इसे एप्लिकेशन से कॉल अप अपवाद बढ़ाता है। कारण - VTABLE में एलओएल() फ़ंक्शन के सूचक के स्थान पर नूल होता है।

जब मैं .h फ़ाइल से .cpp तक LOL() परिभाषा को स्थानांतरित करता हूं, अचानक यह VTABLE में दिखाई देता है और सब कुछ बहुत अच्छा काम करता है। इस व्यवहार को क्या बताता है ?! (जीसीसी कंपाइलर + एआरएम आर्किटेक्चर_)

Answer 1

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

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

जब यह ऐप के लिए समय लिंक करने के लिए मिलता है तो यह QueueClass::_VTABLE के सभी मानों को भरने का प्रयास करता है लेकिन LOL() की परिभाषा नहीं पाता है और इसे खाली (शून्य) छोड़ देता है।

समाधान साझा पुस्तकालय में फ़ाइल में LOL() संदर्भित करना है। &QueueClass::LOL; के रूप में सरल कुछ। संकलक को बिना किसी प्रभाव के शिकायत करना बंद करने के लिए आपको इसे फेंकने वाले चर पर असाइन करने की आवश्यकता हो सकती है।

Answer 2

मेरा अनुमान है कि जीसीसी कॉल को एलओएल में इनलाइन करने का अवसर ले रहा है। मैं देखूंगा कि क्या मैं इस पर आपके लिए एक संदर्भ पा सकता हूं ...

मुझे लगता है कि sechastain मुझे एक और अधिक विस्तृत विवरण में हराया और मैं जिस संदर्भ को ढूंढ रहा था उसे मैं Google नहीं कर सका। तो मैं इसे छोड़ दूंगा।

Answer 3

शीर्षलेख फ़ाइलों में परिभाषित कार्य उपयोग पर रेखांकित हैं। वे पुस्तकालय के हिस्से के रूप में संकलित नहीं हैं; इसके बजाय जहां कॉल किया जाता है, फ़ंक्शन का कोड बस कॉल के कोड को प्रतिस्थापित करता है, और यही संकलित हो जाता है।

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

मुझे यकीन नहीं है कि यह आपके हिस्से पर जल्दबाजी कर रहा है, लेकिन प्रदान किए गए कोड से आईसीएलएएस इंटरफेस में एलओएल, केवल क्यूई क्लास शामिल नहीं है। लेकिन आप एलओएल कॉल करने के लिए आईसीएलएएस इंटरफेस पॉइंटर पर कास्टिंग कर रहे हैं।

Answer 4

यदि यह उदाहरण सरलीकृत है, और आपका वास्तविक विरासत पेड़ एकाधिक विरासत का उपयोग करता है, तो इसे आसानी से समझाया जा सकता है। जब आप ऑब्जेक्ट पॉइंटर पर टाइपकास्ट करते हैं, तो कंपाइलर को पॉइंटर समायोजित करने की आवश्यकता होती है ताकि उचित Vtable संदर्भित किया जा सके। चूंकि आप void * लौट रहे हैं, इसलिए कंपाइलर में समायोजन करने के लिए आवश्यक जानकारी नहीं है।

संपादित करें: वहाँ सी ++ वस्तु लेआउट के लिए कोई मानक नहीं है, लेकिन कैसे एकाधिक वंशानुक्रम काम हो सकता है Bjarne Stroustrup खुद का यह लेख देखें में से एक उदाहरण के लिए: http://www-plan.cs.colorado.edu/diwan/class-papers/mi.pdf

अगर यह वास्तव में आपकी समस्या है, तो आप हो सकता है एक साधारण परिवर्तन के साथ इसे ठीक करने में सक्षम:

IClassInterface *globalMember = new QueueClass(); 

C++ कम्पाइलर आवश्यक सूचक संशोधन कर जब यह, काम करता है ताकि सी समारोह सही सूचक लौट सकते हैं।

Answer 5

मैं @sechastain से असहमत हूं।

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

IClassInterface* i = /**/; 
i->LOL();     // runtime dispatch 
i->QueueClass::LOL();  // compile time dispatch, inline is possible 

@0xDEAD BEEF:

"क्रम प्रेषण का उपयोग कर" की शुद्धता को समझने के लिए मैं अपने डिजाइन कम से कम कहने के लिए भंगुर पाते हैं।

सी-शैली के उपयोग यहाँ डाले गलत है:

QueueClass* p = /**/; 
IClassInterface* q = p; 

assert(((void*)p) == ((void*)q)); // may fire or not... 

मूलरूप कोई गारंटी नहीं कि 2 पतों बराबर हैं है: यह कार्यान्वयन परिभाषित है, और परिवर्तन का विरोध करने की संभावना नहीं है।

मैं तुम्हें तो आप एक IClassInterface* से उसे बनाने के लिए मूल रूप से इतना है कि सी ++ संकलक वस्तुओं के लेआउट पर निर्भर सही सूचक अंकगणित प्रदर्शन कर सकते हैं की जरूरत है सुरक्षित रूप से एक IClassInterface* सूचक को void* सूचक कास्ट करने के लिए सक्षम होने के लिए चाहते हैं।

बेशक, मैं वैश्विक चर के उपयोग की तुलना में भी रेखांकित करूँगा ... आप शायद इसे जानते हैं।

अनुपस्थिति के कारण के रूप में? मैं ईमानदारी से कंपाइलर/लिंकर में एक बग से अलग नहीं देखता हूं। मैंने virtual की अंतर्निहित परिभाषा को कुछ बार देखा है (अधिक विशेष रूप से, clone विधि) और इससे कभी भी समस्याएं नहीं हुईं।

संपादित: चूंकि "सही सूचक अंकगणित" इतनी अच्छी तरह से समझा नहीं गया था, यहां एक उदाहरण

struct Base1 { char mDum1; }; 

struct Base2 { char mDum2; }; 

struct Derived: Base1, Base2 {}; 

int main(int argc, char* argv[]) 
{ 
    Derived d; 
    Base1* b1 = &d; 
    Base2* b2 = &d; 

    std::cout << "Base1: " << b1 
      << "\nBase2: " << b2 
      << "\nDerived: " << &d << std::endl; 

    return 0; 
} 

यहाँ है और क्या छपा था है:

Base1: 0x7fbfffee60 
Base2: 0x7fbfffee61 
Derived: 0x7fbfffee60 

नहीं के बीच का अंतर b2 और &d का मान, भले ही वे एक इकाई का संदर्भ लें। यह समझा जा सकता है अगर कोई ऑब्जेक्ट के मेमोरी लेआउट के बारे में सोचता है।

Derived 
Base1  Base2 
+-------+-------+ 
| mDum1 | mDum2 | 
+-------+-------+ 

जब Base2* को Derived* से परिवर्तित, संकलक (एक बाइट द्वारा सूचक पता यहाँ, बढ़ाने के) आवश्यक समायोजन प्रदर्शन करेंगे ताकि सूचक को प्रभावी ढंग से Derived की Base2 भाग की ओर इशारा करते समाप्त होता है और के लिए नहीं Base1 भाग को गलती से Base2 ऑब्जेक्ट (जो कि बुरा होगा) के रूप में व्याख्या की गई है।

यही कारण है कि डाउनकास्टिंग के दौरान सी-स्टाइल कास्ट का उपयोग करना टालना चाहिए। यहां, यदि आपके पास Base2 पॉइंटर है तो आप इसे Derived पॉइंटर के रूप में पुन: परिभाषित नहीं कर सकते हैं। इसके बजाय, आपको static_cast<Derived*>(b2) का उपयोग करना होगा जो सूचक को एक बाइट द्वारा कम करेगा ताकि यह सही ढंग से Derived ऑब्जेक्ट की शुरुआत को इंगित करे।

मैनिपुलेटिंग पॉइंटर्स को आमतौर पर पॉइंटर अंकगणित के रूप में जाना जाता है। यहां कंपाइलर स्वचालित रूप से प्रकार के बारे में जागरूक होने की स्थिति पर सही समायोजन करेगा।

दुर्भाग्यवश संकलक void* से कनवर्ट करते समय उन्हें निष्पादित नहीं कर सकते हैं, यह इस प्रकार डेवलपर को यह सुनिश्चित करने के लिए है कि वह सही ढंग से इसे संभालता है। अंगूठे का सरल नियम निम्न है: T* -> void* -> T* दोनों पक्षों पर दिखाई देने वाले एक ही प्रकार के साथ।

इसलिए, आपको घोषित करके अपने कोड को सही (सही) करना चाहिए: IClassInterface* globalMember और आपके पास कोई पोर्टेबिलिटी समस्या नहीं होगी। आपके पास अभी भी रखरखाव समस्या होगी, लेकिन ओओ-कोड के साथ सी का उपयोग करने की समस्या है: सी किसी ऑब्जेक्ट उन्मुख सामग्री के बारे में पता नहीं है।