2012-03-13 12 views
6

हम सभी जानते हैं कि तार्किक && ऑपरेटर शॉर्ट सर्किट यदि बाएं ऑपरेंड false है, क्योंकि हम जानते हैं कि यदि एक ऑपरेंड false है, तो परिणाम भी false है।बिटवाई और ऑपरेटर शॉर्ट-सर्किट क्यों नहीं है?

बिटवाई & ऑपरेटर भी शॉर्ट-सर्किट क्यों नहीं करता है? यदि बाएं ऑपरेंड 0 है, तो हम जानते हैं कि परिणाम भी 0 है। मैंने जिस भाषा में इसका परीक्षण किया है (सी, जावास्क्रिप्ट, सी #) पहले के बाद रोकने के बजाय दोनों ऑपरेटरों का मूल्यांकन करता है।

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

+1

एक कारण फ़ंक्शन कॉल के दुष्प्रभावों की अनुमति देना होगा। –

+3

चूंकि बिटवाई ऑपरेटर आमतौर पर पूर्णांक ऑपरेटरों पर बिटवाई ऑपरेशंस के लिए उपयोग किए जाते हैं (और वे आमतौर पर एकल मशीन निर्देशों के अनुरूप होते हैं) यह दुर्लभ 0 मामलों की जांच के लिए अतिरिक्त सशर्त पेश करने के अनुकूलन के अलावा कुछ और होगा। गुणांक 0 पर शॉर्ट सर्किट क्यों नहीं करता है? खैर, क्योंकि यह एक मशीन अंक के अनुरूप एक सरल अंकगणितीय ऑपरेशन है और जांच रहा है कि कोई भी 0 ऑपरेंड के लिए प्रत्येक गुणा की जांच नहीं करेगा। –

+0

बाएं ऑपरेशन '0xFFFFFFFF था अगर bitwise' | 'ऑपरेटर शॉर्ट सर्किट सकता है। –

उत्तर

9

मुझे लगता है कि यह इसलिए है क्योंकि स्रोत भाषा में थोड़ा सा and प्रोसेसर द्वारा निष्पादित करने के लिए आमतौर पर थोड़ा सा and निर्देश का अनुवाद किया जाता है। बदले में, हार्डवेयर में and द्वारों की उचित संख्या के समूह के रूप में लागू किया गया है।

मुझे यह ज्यादातर मामलों में कुछ भी अनुकूलित करने के रूप में नहीं दिख रहा है। दूसरे ऑपरेंड का मूल्यांकन करना आम तौर पर यह देखने के लिए परीक्षण से कम खर्च करेगा कि आपको इसका मूल्यांकन करना चाहिए या नहीं।

+1

यह लाभ होगा यदि दूसरे ऑपरेंड में महंगी गणना शामिल थी। –

+3

@ पीटर ओल्सन हाँ, और केवल दुर्लभ मामले में बाएं ऑपरेंड 0 है। याद रखें कि हम यहां पूर्णांक के बारे में बात कर रहे हैं और 0 का एक पूर्णांक मान 'झूठा' के बूलियन मान से कहीं अधिक दुर्लभ है (भले ही शायद अधिक बार अन्य नंबर)। –

2

बिटवाई ऑपरेशंस आमतौर पर इतना सस्ता होता है कि चेक ऑपरेशन को दो बार या अधिक लंबे समय तक बनाएगा, जबकि लॉजिकल ऑपरेटर को शॉर्ट-सर्किट करने से लाभ संभवतः बहुत बढ़िया है।

2

यदि कंपाइलर को & दोनों ऑपरेटरों के लिए चेक उत्सर्जित करना है, तो मुझे लगता है कि आप किसी भी सामान्य स्थिति में बहुत धीमे हो जाएंगे।

7

लघु-सर्किटिंग एक अनुकूलन डिवाइस नहीं है। यह एक नियंत्रण प्रवाह उपकरण है। यदि आप शॉर्ट सर्किट p != NULL && *p != 0 में विफल रहते हैं, तो आपको थोड़ा धीमा कार्यक्रम नहीं मिलेगा, आपको एक क्रैशिंग प्रोग्राम मिलेगा।

इस प्रकार का शॉर्ट-सर्किटिंग लगभग बिटवाई ऑपरेटरों के लिए कभी भी समझ में नहीं आता है, और सामान्य गैर-शॉर्ट-सर्किटिंग ऑपरेटर से अधिक महंगा है।

+1

यह तर्क मेरे पीछे की ओर लगता है। शॉर्ट सर्किटिंग को फ्लो कंट्रोल डिवाइस के रूप में इस्तेमाल किया जा सकता है * क्योंकि * यह अनुकूलन के रूप में मौजूद है। यदि '&& 'शॉर्ट सर्किट नहीं था, तो इस तरह का कोड कभी लिखने के लिए मान्य नहीं होगा; यह दो अलग-अलग परीक्षण होना होगा। हालांकि, मैं मानता हूं कि अभ्यास में थोड़ा सा सर्किटिंग पर्याप्त दुर्लभ होगा कि यह लंबे समय तक शायद अधिक महंगा होगा। यह सब कॉलिंग कोड के संदर्भ में बाएं ऑपरेंड के लिए 0 मान की संभावना पर निर्भर करता है। –

+0

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

1

इसी कारण से * शॉर्ट-सर्किट नहीं है यदि पहला ऑपरेंड 0 है - यह एक अस्पष्ट विशेष मामला होगा और इसके लिए विशेष रनटाइम परीक्षण जोड़ना सभी गुणा धीमा कर देगा।

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

संबंधित मुद्दे