👨🏻‍⚕️ ✍🏿 🕋 सी ++, सी-स्टाइल कास्ट और उनके संयोजन के अप्रत्याशित परिणाम ⛹🏽 🛏️ 😌

C ++ को एक टाइप कास्ट (प्रकार) (किस कास्ट) से विरासत में मिला है - आमतौर पर C कास्ट कहा जाता है। C ++ में चार और स्पष्ट कास्ट हैं- static_cast, reinterpret_cast, dynam_cast, const_cast।

C ++ नवीनतम भाषा नहीं है, और इसके बारे में गर्म बहस बेहतर है - C की शैली में डाली गई या सही संयोजन में * _cast का उपयोग करते हुए, बहुत पहले शुरू हुआ और आज तक नहीं थमा। हम आग में ईंधन नहीं जोड़ेंगे, हम एक उदाहरण पर बेहतर विचार करेंगे और सभी को यह तय करने देंगे कि उसे क्या पसंद है।

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

एक वास्तविक ओपन सोर्स प्रोजेक्ट से वास्तविक कोड पर आधारित एक उदाहरण। परियोजना के एक निश्चित उपतंत्र में, एक वर्ग को घोषित किया गया है जो कई COM इंटरफेस को लागू करता है:

 class CInterfacesImplementor : public IComInterface1, public IComInterface2, public IComInterface3, ...(   4  9), public IComInterface10 { //    };

बेशक, वास्तविक जीवन में, इंटरफेस में अधिक सार्थक नाम हैं, लेकिन जब वे एक दर्जन के करीब होते हैं, तो बाद में चर्चा की गई समस्या से बहुत मदद नहीं मिलती है।

याद रखें कि प्रत्येक COM इंटरफ़ेस प्रत्यक्ष या अप्रत्यक्ष रूप से IUnogn से विरासत में मिला है, और IUnogn में QueryInterface () विधि है, जिसका सही कार्यान्वयन इतना मुश्किल है कि रेमंड चेन ने इस श्रृंखला ( यहां , यहां और यहां ) के बारे में लिखा है।

हमारा उदाहरण सिर्फ ऊपर की कक्षा में QueryInterface () का कार्यान्वयन है। संक्षिप्त पृष्ठभूमि: जब कोई डेवलपर नए COM इंटरफ़ेस की घोषणा करता है, तो वह उसे एक विशिष्ट पहचानकर्ता नियुक्त करने के लिए बाध्य होता है। कॉलर यह जानने के लिए QueryInterface () कॉल करता है कि क्या ऑब्जेक्ट ऐसे आइडेंटिफ़ायर के साथ एक इंटरफ़ेस को लागू करता है और, यदि यह लागू होता है, तो इसी प्रकार का पॉइंटर प्राप्त करें। __Uuidof () निर्माण दृश्य C ++ को संकलन समय पर कोष्ठक में इंगित इंटरफ़ेस के पहचानकर्ता को खोजने और स्थानापन्न करने के लिए कहता है।

इसलिए ...

 HRESULT STDMETHODCALLTYPE CInterfaceImplementor::QueryInterface( REFIID iid, void** ppv ) { if( ppv == 0 ) { return E_POINTER; } if( iid == __uuidof( IUnknown ) || iid == __uuidof( IComInterface1 ) ) { *ppv = (IComInterface1*)this; } else if( iid == __uuidof( IComInterface2 ) ) { *ppv = (IComInterface2*)this; } else if( iid == __uuidof( IComInterface3 ) ) { *ppv = (IComInterface3*)this; } else if... ... //       COM- } else { //   COM-     *ppv = 0; return E_NOINTERFACE; } AddRef(); return S_OK; }

कार्य के ऊपर कार्यान्वयन लगभग सही है। वह सूचक को dereferencing से पहले चेक करता है। यदि कोई ज्ञात इंटरफ़ेस उससे अनुरोध किया गया था, तो वह जांचती है। यह E_NOINTERFACE कोड वापस करने से पहले एक अशक्त सूचक लिखता है। यह संदर्भ गणना को बढ़ाता है यदि इंटरफ़ेस समर्थित है। यहां तक कि वह IUnogn अनुरोध का सही ढंग से जवाब देता है। रेमंड चेन प्रसन्न होगा यदि एक प्रश्न के लिए नहीं।

भूत क्यों हैं? "* Ppv = this" क्यों नहीं लिखा?

एकाधिक वंशानुक्रम के साथ, ऑब्जेक्ट बेस कक्षाओं के सबोबिज के "रचित" होगा ताकि आप प्रत्येक सबजेक्ट को अलग से एक्सेस कर सकें। कहो, कुछ फ़ंक्शन केवल IComInterface2 * के साथ काम कर सकते हैं - आपको इसे इस विशेष उप-प्रक्षेपक के लिए एक संकेतक पास करने की आवश्यकता है, और एक व्युत्पन्न वस्तु को नहीं, जिनमें से यह संभवतः, कुछ भी नहीं जानता है।

"* Ppv = this?" असाइन करने से, व्युत्पन्न वस्तु के प्रारंभ का पता हर बार प्रेषित किया जाएगा, और इसके उप-विषय नहीं होते। एक वर्चुअल इंटरफ़ेस विधि को एक पॉइंटर के माध्यम से दूसरे सबोबिज में कॉल करने का प्रयास स्पष्ट रूप से एक लंबी डिबगिंग का कारण होगा।

उपरोक्त उदाहरण सिर्फ पॉइंटर समायोजन प्रदान करता है। यह आवश्यक है ताकि कॉल करने वाले को विशेष रूप से वांछित सबोबिज में एक संकेतक प्राप्त हो।

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

उसी ओपन सोर्स प्रोजेक्ट के एक अन्य सबसिस्टम में, एक और वर्ग है जो समान इंटरफेस के सेट को लागू करता है:

 class CYetOtherImplementor : public IComInterface1, public IComInterface3, ...(   4  9), public IComInterface10 { //    };

और, स्वाभाविक रूप से, कोई भी उस स्थिति की श्रृंखला को नए सिरे से लिखना नहीं चाहता है, इसलिए लागू होने के बाद से सभी अधिक स्पष्ट रूप से समान हैं:

 HRESULT STDMETHODCALLTYPE CYetOtherImplementor::QueryInterface( REFIID iid, void** ppv ) { if( ppv == 0 ) { return E_POINTER; } if( iid == __uuidof( IUnknown ) || iid == __uuidof( IComInterface1 ) ) { *ppv = (IComInterface1*)this; } else if( iid == __uuidof( IComInterface2 ) ) { *ppv = (IComInterface2*)this; } else if( iid == __uuidof( IComInterface3 ) ) { *ppv = (IComInterface3*)this; } else if... ... //       COM- } else { //   COM-     *ppv = 0; return E_NOINTERFACE; } // V2UncmUgaGlyaW5nIC0gd3d3LmFiYnl5LnJ1L3ZhY2FuY3k= AddRef(); return S_OK; }

अब मानसिक रूप से खोना क्या होता है जब IComInterface2 इंटरफ़ेस का अनुरोध किया जाता है। नियंत्रण यदि पहचानकर्ता से मेल खाता है, तो आईएफ-और-यदि श्रृंखला का पालन करेगा, और फिर सी-स्टाइल कास्ट किया जाएगा।

C ++ मानक ISO / IEC 14882: 2003 (E) की धारा 5.3.5 / 5 में कहा गया है कि C शैली में कास्टिंग करते समय या तो static_cast निष्पादित किया जाएगा (हमारे मामले में), या यदि static_cast संभव नहीं है, तो reinter_cast।

पहले उदाहरण में, क्लास को IComInterface2 से विरासत में मिला था और इस पॉइंटर के static_cast को पॉइंटर से मनचाहे सबोबिज में ले जाया गया था।

दूसरे उदाहरण में, श्रेणी अब IComInterface2 (हाँ, कॉपी-पेस्ट प्लस फ़ाइल संशोधन) से विरासत में मिली है, इसलिए static_cast संभव नहीं है। Reinterpret_cast निष्पादित किया जाएगा, इस सूचक को अपरिवर्तित कॉपी किया जाएगा। और वैसे, ऑब्जेक्ट IComInterface2 को बिल्कुल भी लागू नहीं करता है। शब्द "अचानक" यहाँ उपयुक्त है।

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

तुलना के लिए, यदि आप if-else-if शाखाओं में से प्रत्येक में static_cast का उपयोग करते हैं, तो संकलक एक त्रुटि संदेश देगा और दूसरा उदाहरण संकलित नहीं करेगा, यह धीरे से डेवलपर को संकेत देगा कि हमें फ़ाइल के साथ थोड़ा और काम करने की आवश्यकता है। कम डिबगिंग दिन, आप कुछ उपयोगी कर सकते हैं।

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

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

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

दिमित्री मेश्चेरीकोव

डाटा एंट्री उत्पाद विभाग

सी ++, सी-स्टाइल कास्ट और उनके संयोजन के अप्रत्याशित परिणाम

More articles: