लॉजिकल ऑपरेटर ओवरलोडिंग खराब अभ्यास माना जाता है?

Question

क्या & & पर अधिभारित करना बुरा विचार है, || या अल्पविराम ऑपरेटर और क्यों?

Answer 1

मैं operator&& या operator|| अधिभारित नहीं करता। यहां तक ​​कि यदि आप एक वर्ग को परिभाषित करते हैं जो बूलियन बीजगणित (उदाहरण के लिए सीमित सेट) को जन्म देता है, तो शायद operator& और operator| को अधिभारित करने के लिए यह बेहतर विकल्प होगा।

कारण यह है कि सी ++ प्रोग्रामर operator&& और operator|| के लिए विशेष अर्थ विज्ञान की उम्मीद है: वे शॉर्ट सर्किट, अर्थात उनके दाएँ हाथ तर्क यदि आवश्यक हो तो नहीं का मूल्यांकन नहीं है। आप इस व्यवहार को ओवरलोडिंग से नहीं प्राप्त कर सकते हैं, क्योंकि आप एक फ़ंक्शन को परिभाषित करेंगे।

ओवरलोडिंग operator, उदाहरण में किया गया है Boost.Assign पुस्तकालय। यह मेरा ओवरलोडिंग का एकमात्र उदाहरण भी है जो मुझे पता है, और मैंने इसे कभी भी अधिभारित नहीं माना है। आप बेहतर इसके लिए एक बहुत ही विशिष्ट उपयोग केस होगा जहां कोई अन्य ऑपरेटर उपयुक्त नहीं है।

Answer 2

सी ++ में लॉजिकल ऑपरेटरों को अधिभारित करने के लिए, ऑपरेटरों का मूल्यांकन किया जाना चाहिए, जो सामान्य रूप से अंतर्निहित प्रकारों के छोटे सर्किटिंग के साथ काम नहीं करते हैं।

नीचे दिए गए लिंक को देखें।

• Don't overload logical operators in C++

Answer 3

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

Answer 4

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

Answer 5

जैसा कि अन्य ने कहा है, आलसी मूल्यांकन खोना तार्किक ऑपरेटरों को अधिभारित करने से बचने का मुख्य कारण है।

हालांकि, उन्हें अधिभारित करने का एक बहुत अच्छा कारण है: Expression templates। Boost.Lambda लाइब्रेरी यह करता है, और यह बहुत उपयोगी है!

Answer 6

यह आमतौर पर एक बुरा विचार है: उन तीन ऑपरेटरों के पास अनुक्रमिक प्रभाव होता है जो उन्हें ओवरलोड करते समय खो जाता है। उस अनुक्रमित प्रभाव को खोने से उन लोगों को हाथ (यानी अजीब बग) का कारण बन सकता है जो खोने की अपेक्षा नहीं करते हैं।

ऐसे टेम्पलेट अभिव्यक्तियों के मामले हैं जहां आप अनुक्रमित प्रभाव रख सकते हैं, उन मामलों में मुझे उन्हें ओवरलोड करने में कोई समस्या नहीं है।

operator, का अधिभार मुझे एक और समस्या है: वे इस तरह से काम करते हैं कि संचालन की स्पष्ट श्रृंखला असली नहीं है। आम तौर पर, जब वे कोई फर्क नहीं पड़ता, तो संदर्भ में उनका उपयोग किया जाता है, लेकिन एक बार नीले चंद्रमा में, यह एक अजीब बग का एक और स्रोत है।

Answer 7

आपको किसी भी ऑपरेटरों को आश्चर्यजनक तरीके से अधिभारित नहीं करना चाहिए।:-)

यदि आप इसे ऐसे तरीके से कर सकते हैं जो समझ में आता है (न केवल आपके लिए), तो ऐसा करना ठीक है।

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