क्या आप अभी भी उबल रहे हैं और इसकी तुलना शून्य से कर रहे हैं?

एक बार एक दूर की आकाशगंगा में, MFC लाइब्रेरी का व्यापक रूप से उपयोग किया गया था, जिसमें कई वर्गों में तरीकों की तुलना शून्य से की गई थी। कुछ इस तरह:

class CWindow { HWND handle; HWND GetSafeHandle() const { return this == 0 ? 0 : handle; } }; 

"इसका कोई मतलब नहीं है," पाठक को आपत्ति होगी। इसका एक "है" भी है: यह कोड "अनुमति देता है" को गेट्सफैंडल () विधि को कॉल करने के लिए null पॉइंटर CWindow * के माध्यम से। इस तकनीक का उपयोग समय-समय पर विभिन्न परियोजनाओं में किया जाता है। विचार करें कि यह वास्तव में एक बुरा विचार क्यों है।

हमें इस तथ्य से शुरू करना होगा कि, सी ++ मानक के अनुसार (आईएसओ / आईईसी 14882: 2003 (ई) मानक के 5.2.5 / 3 से निम्नानुसार), किसी भी वर्ग के किसी भी गैर-स्थिर तरीके को एक शून्य सूचक के माध्यम से कॉल करने से अपरिभाषित व्यवहार होता है। फिर भी, कई क्रियान्वयनों में, इस तरह का कोड अच्छी तरह से काम कर सकता है:

 class Class { public: void DontAccessMembers() { ::Sleep(0); } }; int main() { Class* object = 0; object->DontAccessMembers(); } 

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

 class Class { public: static void DontAccessMembers(Class* currentObject) { ::Sleep(0); } }; int main() { Class* object = 0; Class::DontAccessMembers(object); } 

यदि विधि को वस्तुतः कहा जाता था, तो देर से बाध्यकारी आवश्यक होगा, जो आमतौर पर एक संकेतक के माध्यम से एक विशिष्ट वस्तु की शुरुआत में वर्चुअल विधि तालिका में लागू किया जाता है। इस मामले में, यहां तक ​​कि यह पता लगाने के लिए कि किस विधि को कॉल करने की आवश्यकता है, यह ऑब्जेक्ट की सामग्री तक पहुंचने के लिए आवश्यक है, और एक शून्य पॉइंटर के मामले में, यह सबसे अधिक संभावना है कि प्रोग्राम क्रैश हो जाएगा।

लेकिन हम जानते हैं कि हमारी पद्धति को वस्तुतः कभी सही नहीं कहा जाएगा? सामान्य तौर पर, यह कोड कुछ वर्षों से वहां काम कर रहा है।

समस्या यह है कि कंपाइलर अनुकूलन के लिए अपरिभाषित व्यवहार का उपयोग कर सकता है। यहाँ एक उदाहरण है:

 int divideBy = …; whatever = 3 / divideBy; if( divideBy == 0 ) { // THIS IS IMPOSSIBLE } 

उपरोक्त कोड में, divideBy द्वारा पूर्णांक विभाजन किया जाता है। शून्य से पूर्णांक विभाजन अपरिभाषित व्यवहार की ओर जाता है (आमतौर पर कार्यक्रम को क्रैश करने के लिए)। इसका मतलब है कि हम मान सकते हैं कि चर divideBy शून्य के बराबर नहीं है, और संकलन चरण में, सत्यापन को बाहर करें और तदनुसार कोड का अनुकूलन करें।

उसी तरह, कंपाइलर कोड की तुलना शून्य से कर सकता है। मानक के अनुसार, यह शून्य नहीं हो सकता; तदनुसार, चेक और संबंधित कोड शाखाओं को बाहर रखा जा सकता है, और यह कोड को महत्वपूर्ण रूप से प्रभावित करेगा, जो शून्य के साथ तुलना करने पर निर्भर करता है। कंपाइलर को "ब्रेक" (वास्तव में, ब्रेक) CWindow :: GetSafeHandle () कोड और मशीन कोड उत्पन्न करने का पूर्ण अधिकार है जिसमें कोई तुलना नहीं है, लेकिन क्लास फ़ील्ड हमेशा पढ़ा जाता है।

अब तक, आम संकलक के नवीनतम संस्करण (आप जीसीसी एक्सप्लोरर सेवा का उपयोग करके जांच कर सकते हैं) इस तरह के अनुकूलन नहीं करते हैं, इसलिए अभी "सब कुछ काम करता है", ठीक है?

सबसे पहले, घृणा करें जब आप एक दूसरे कंपाइलर या उसी कंपाइलर के किसी अन्य संस्करण पर स्विच करने के बाद बहुत दुखी होंगे, तो आप यह पता लगाने के लिए बहुत समय बिताते हैं कि अब ऐसा अनुकूलन क्या है। इसलिए, ऊपर दिया गया कोड पोर्टेबल नहीं है।

दूसरे,

 class FirstBase { int firstBaseData; }; class SecondBase { public: void Method() { if( this == 0 ) { printf( "this == 0"); } else { printf( "this != 0 (value: %p)", this ); } } }; class Composed1 : public FirstBase, public SecondBase { }; int main() { Composed1* object = 0; object->Method(); } 

WELL SHOULD, जब विजुअल C ++ 9 पर संकलित किया जाता है, तो विधि के प्रवेश द्वार पर यह पॉइंटर 0x00000004 है, क्योंकि शुरू में null पॉइंटर को संबंधित वर्ग के सबोबिज की शुरुआत में इंगित करने के लिए समायोजित किया जाता है।

और अगर आप आधार वर्गों के क्रम को बदलते हैं

 class Composed2 : public SecondBase, public FirstBase { }; int main() { Composed2* object = 0; object->Method(); } 

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

यह देखना आसान है कि Composed1 वर्ग के मामले में, एक ऑब्जेक्ट के लिए एक पॉइंटर को ऑब्जेक्ट के लिए पॉइंटर का अंतर्निहित रूपांतरण "गलत तरीके से" काम करता है - किसी ऑब्जेक्ट के लिए एक शून्य पॉइंटर के लिए, रूपांतरण सब -जेक्ट पर एक गैर-शून्य पॉइंटर देता है। आमतौर पर, एक ही रूपांतरण को लागू करते समय, कंपाइलर एक सूचक को शून्य की समानता के लिए एक चेक जोड़ता है। उदाहरण के लिए, अपरिभाषित व्यवहार के साथ ऐसे कोड को संकलित करना (Composed1 वर्ग ऊपर के समान है):

 SecondBase* object = reinterpret_cast<Composed1*>( rand() ); object->Method(); 

दृश्य C ++ 9 में निम्नलिखित मशीन कोड देता है:

 SecondBase * ऑब्जेक्ट = reinterpret_cast <Composed1 *> (रैंड ());
 010C1000 कॉल ड्राफ्ट ptr [__imp__rand (10C209Ch)] 
 010C1006 टेस्ट ईएक्स, ईएक्सएक्स
 010C1008 je wmain + 0Fh (10C100Fh) 
 010C100A जोड़ें eax, 4 
 ऑब्जेक्ट-> विधि ();
 010C100D jne wmain + 20h (10C1020h) 
 010C100F पुश ऑफसेट स्ट्रिंग "यह == 0" (10C20F4h) 
 010C1014 कॉल ड्राफ्ट ptr [__imp__printf (10C20A4h)] 
 010C101A esp जोड़ें, 4 

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

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

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

दिमित्री मेश्चेरीकोव,
डेवलपर उत्पाद विभाग