🛷 ☝🏾 🐓 एक परिभाषा नियम, इनलाइन और उनके संयोजन के अप्रत्याशित परिणाम 🧖🏿 👉🏼 👭

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

इनलाइन फ़ंक्शन आमतौर पर हेडर फ़ाइलों (.h) में परिभाषित किए जाते हैं ताकि सभी अनुवाद इकाइयां फ़ंक्शन के कार्यान्वयन को देख सकें और कॉल के स्थान पर इसे प्रतिस्थापित कर सकें। तदनुसार, जैसे ही आप एक से अधिक प्रसारण इकाई में ऐसे फ़ंक्शन के साथ एक हेडर फ़ाइल शामिल करते हैं, ओडीआर का औपचारिक रूप से उल्लंघन किया जाएगा, लेकिन ... आपको किसी त्रुटि का संकेत नहीं मिलेगा।

क्यों और क्या अप्रत्याशित परिणाम हो सकते हैं?

क्यों - प्रश्न अपेक्षाकृत अच्छी तरह से जाना जाता है ( उदाहरण के लिए )। एक ओर, ऊपर वर्णित स्थिति को व्यावहारिक कारणों से निषिद्ध नहीं किया जा सकता है - यह आवश्यक है कि फ़ंक्शन सभी अनुवाद इकाइयों से सुलभ है जो इसे कहते हैं, अन्यथा प्रतिस्थापन संभव नहीं हो सकता है। दूसरी ओर, ओडीआर टूट गया है और इस पर प्रतिक्रिया देना अच्छा होगा।

प्रतिक्रिया देने के दो तरीके हैं - एक त्रुटि संदेश या मौन। इस विशेष मामले में, लिंकर दूसरे का चयन करता है। जैसे ही लिंकर एक ही नाम और एक ही हस्ताक्षर के साथ एक से अधिक इनलाइन फ़ंक्शन देखता है, यह मानता है कि यह एक ही फ़ंक्शन है और अपने विवेक पर उनमें से एक का चयन करता है।

इसलिए औपचारिक रूप से ओडीआर का उल्लंघन समाप्त हो गया है।

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

~~धीरे-धीरे सरगर्मी,~~ थोड़ा प्रीप्रोसेसर जोड़ें (उदाहरण के लिए, यह एटीएल में त्रुटि हैंडलर के लिए किया जाता है ):

 //CommonFile.h __declspec( noinline ) //  noinline inline void HandleErrorCondition( int condition ) { #ifndef OVERRIDE_STANDARD_HANDLING _exit(1); #else CustomHandleErrorCondition( condition ); #endif } //StaticLib.h #include <CommonFile.h> inline void SomeUsefulFunction() { //blahblahblah HandleErrorCondition( 0 ); } //StaticLib.cpp #include <StaticLib.h> blahblahblah,  SomeUsefulFunction() //Executable.cpp void CustomHandleErrorCondition( int condition ) { throw MyCustomException( condition ); } #define OVERRIDE_STANDARD_HANDLING #include <StaticLib.h> blahblahblah,  SomeUsefulFunction() //V2UncmUgaGlyaW5nIC0gd3d3LmFiYnl5LnJ1L3ZhY2FuY3k=

StaticLib.cpp StaticLib.lib स्टेटिक लाइब्रेरी के लिए संकलित करता है, फिर Executable.cpp एक निष्पादन योग्य फ़ाइल (.exe या .dll - वैसे भी) के लिए संकलित करता है और StaticLib.lib को जोड़ता है।

HandleErrorCondition () हस्ताक्षर में __declspec (noinline) शामिल है, एक विजुअल C ++ विशेषता जो संकलक को बताती है कि आपको इस फ़ंक्शन के कार्यान्वयन को प्रतिस्थापित करने की आवश्यकता नहीं है। यह विशेष रूप से किया जाता है ताकि संकलक फ़ंक्शन के कार्यान्वयन को प्रतिस्थापित न करे और कार्यान्वयन को बाद में प्रतिस्थापित किया जा सके। दृश्य C ++ का पालन करता है।

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

क्या यह काम करेगा? HandleErrorCondition () - _exit () के लिए कॉल के साथ या CustomHandleErrorCondition () के कॉल के साथ कौन सा कार्यान्वयन कहा जाएगा?

अज्ञात।

जब कंपाइलर StaticLib.cpp को संकलित करता है, तो इसमें ऑब्जेक्ट फ़ाइल (StaticLib.obj) में पहला कार्यान्वयन शामिल होता है - _exit () पर कॉल के साथ। जब कंपाइलर Executable.cpp को संकलित करता है, तो इसमें ऑब्जेक्ट फ़ाइल (Executable.obj) में एक दूसरा कार्यान्वयन शामिल होता है - CustomHandleErrorCondition () के लिए एक कॉल के साथ।

लिंक करते समय, ऊपर वर्णित ODR उल्लंघन स्थिति होती है, लेकिन अब लिंकर द्वारा उपयोग की जाने वाली नीति के दृष्टिकोण से समान दो इनलाइन फ़ंक्शन, अलग-अलग कार्यान्वयन हैं। लिंकर एक का चयन करेगा और इस तथ्य का नहीं कि पसंद एक लिंक से दूसरे लिंक में नहीं बदलेगी।

अचानक, आपका कार्यक्रम आपकी योजना के अनुसार काम नहीं करता है। विशेष रूप से अच्छा क्या है, इस उदाहरण में व्यवहार केवल प्रसंस्करण त्रुटियों के दौरान भिन्न होगा, अर्थात। अपेक्षाकृत दुर्लभ परिस्थितियों में और इस तथ्य से नहीं कि वे जांचना नहीं भूलेंगे।

दृश्य सी ++ द्वारा वर्णित व्यवहार (कार्यों में से एक को चुनना) प्रदर्शित किया जाता है। कुछ पाठक पहले से ही कास्टिक टिप्पणी लिखने की तैयारी कर रहे हैं, लेकिन व्यर्थ। सी ++ आईएसओ / आईईसी 14882: 2003 (ई), पैरा 3.2 / 5 के अनुसार वर्णित व्यवहार को परिभाषित नहीं किया गया है। तदनुसार, लिंकर किसी भी उचित परिणाम देने के लिए बाध्य नहीं है, न ही समान ऑब्जेक्ट फ़ाइलों को फिर से लिंक करने पर समान परिणाम देने के लिए। कुछ मामलों में, व्यवहार वही होगा जो आप उम्मीद करते थे, कुछ में, शायद नहीं। तो विजुअल C ++ निर्दोष है।

यह ध्यान देने का समय है कि उदाहरण कृत्रिम और टेढ़ा लग रहा है। फिर, __declspec (noinline) विज़ुअल C ++ के लिए विशिष्ट सुविधा है। अपने आप को ठीक उसी स्थिति में खोजने के कई अन्य तरीके हैं।

उदाहरण के लिए, दो अलग-अलग हेडर में, एक ही हस्ताक्षर के साथ इनलाइन फ़ंक्शन गलती से दिखाई दे सकते हैं। यदि ऐसी कोई स्थिति नहीं है जहां दोनों हेडर को एक ही .cpp फ़ाइल में शामिल किया गया है, तो आपको संकलन त्रुटि नहीं मिलेगी और फिर आप अपने आप को ODR उल्लंघन स्थिति में पाएंगे। विभिन्न .cpp फ़ाइलों को कुछ संकलक सेटिंग के विभिन्न मूल्यों के साथ संकलित किया जा सकता है, जो कोड के व्यवहार को बदलता है। फिर से वही स्थिति। #pragma पैक भी योगदान दे सकता है।

अंत में, यदि __declspec (noinline) अनुपस्थित है, तो कुछ मामलों में कंपाइलर कंप्लायंस सेटिंग्स और प्रीप्रोसेसर चिह्नों के अनुरुप फंक्शन ट्रांसलेशन का विकल्प दे सकता है।

इस दिशा में दोषों की गुंजाइश अनंत है। ऐसे दोषों का पता लगाना, जब वे पहले से ही आपके कोड में हैं, बेहद मुश्किल है। लिंक करने के दौरान कार्यक्रम का व्यवहार बदल सकता है, या यह समान रह सकता है - तदनुसार, एक दोष भी पुन: उत्पन्न करना मुश्किल हो सकता है।

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

ऊपर वर्णित मामले में, आपको StaticLib परियोजना में OVERRIDE_STANDARD_HANDLING को परिभाषित करने और इसे पुनर्निर्माण करने की आवश्यकता है।

अपना ख्याल रखना।

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

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

एक परिभाषा नियम, इनलाइन और उनके संयोजन के अप्रत्याशित परिणाम

More articles: