अगर पहले बयान में स्थिरांक डालने के पीछे क्या तर्क है?

Question

मैं कुछ उदाहरण सी एक हार्डवेयर इंटरफेस के साथ मैं काम कर रहा हूँ के लिए ++ कोड देख रहा था और निम्नलिखित लाइनों के साथ बयान का एक बहुत देखा:

if (NULL == pMsg) return rv; 

मुझे यकीन है कि मैंने सुना है हूँ लोग कहते हैं कि डाल निरंतर पहले एक अच्छा विचार है, लेकिन वह क्यों है? क्या यह सिर्फ इतना है कि यदि आपके पास एक बड़ा कथन है तो आप जल्दी से देख सकते हैं कि आप किस चीज की तुलना कर रहे हैं या इसके लिए और भी कुछ है?

Answer 1

ताकि आप तुलना (==) असाइनमेंट (=) के साथ मिश्रण (==) मिश्रण न करें।

जैसा कि आप जानते हैं, आप निरंतर असाइन नहीं कर सकते हैं। यदि आप कोशिश करते हैं, तो शिकायतकर्ता आपको एक त्रुटि देगा।

असल में, यह रक्षात्मक प्रोग्रामिंग तकनीकों में से एक है। खुद से खुद को बचाने के लिए।

Answer 2

जब स्थिर पहले होता है, तो संकलक आपको चेतावनी देगा यदि आप गलती से === के बजाय लिखते हैं क्योंकि यह निरंतर मूल्य को असाइन करना अवैध है। गलती से

if (pMsg = NULL) return rv; 

:

Answer 3

लेखन से आप को रोकने के लिए। एक अच्छा संकलक आपको इसके बारे में चेतावनी देगा हालांकि, अधिकांश लोग "निरंतर पहले" तरीके का उपयोग नहीं करते हैं, क्योंकि उन्हें पढ़ने में मुश्किल होती है।

Answer 4

यह एकल = असाइनमेंट बग रोकता है।

जैसे,

if (NULL = pMsg) return rv; 

संकलन नहीं होगा, जहां के रूप में

if (pMsg = NULL) return rv; 

संकलन और दे देंगे आप सिर दर्द

Answer 5

उन्होंने कहा, "काम और तुलना के मिश्रण को रोकने के लिए"।

हकीकत में मुझे लगता है कि यह बकवास है: यदि आप तो अनुशासित आप भूल नहीं है कि बाईं ओर निरंतर डाल करने के लिए कर रहे हैं, तो आप निश्चित रूप से अप '=' के साथ मिश्रण नहीं होगा '==' , क्या तुम? ;)

Answer 6

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

Answer 7

कुछ टिप्पणियों में मैंने जो लिखा है उसे स्पष्ट करने के लिए, यहां C12+ कोड में ऐसा करने के लिए का कारण नहीं है।

किसी लिखते हैं, कहते हैं, एक स्ट्रिंग वर्ग और const char* करने के लिए एक डाली ऑपरेटर जोड़ने का निर्णय:

BadString s("foo"); 

if ("foo" == s) // Oops. This compares pointers and is never true. 
{ 
    // ... 
} 

यह वह जगह है:

class BadString 
{ 
public: 
    BadString(const char* s) : mStr(s) { } 

    operator const char*() const { return mStr.c_str(); } 

    bool operator==(const BadString& s) { return mStr == s.mStr; } 

    // Other stuff... 

private: 
    std::string mStr; 
}; 

अब किसी को आँख बंद करके constant == variable "बचाव की मुद्रा में" प्रोग्रामिंग पैटर्न लागू होता है , आईएमओ, आकस्मिक असाइनमेंट की तुलना में एक और कपटपूर्ण समस्या है क्योंकि आप कॉल साइट से नहीं बता सकते कि कुछ भी स्पष्ट रूप से गलत है।

बेशक, असली सबक हैं:

1. अपनी खुद की स्ट्रिंग कक्षाएं न लिखें।
2. निहित कलाकारों से बचें, खासकर जब (1) कर रहे हों।

लेकिन कभी-कभी आप तीसरे पक्ष के एपीआई से निपट रहे हैं जिन्हें आप नियंत्रित नहीं कर सकते हैं। उदाहरण के लिए, Windows COM प्रोग्रामिंग में _bstr_t स्ट्रिंग क्लास सामान्य इस दोष से पीड़ित है।

Answer 8

मैं लेख भूल जाते हैं, लेकिन बोली की तरह कुछ चला गया: "जाहिर है इसकी आसान, निरंतर पहले डाल करने के लिए की तुलना में यह उपयोग करने के लिए == याद है याद";))