शून्य एक स्थिर के रूप में?

Question

मैं इस प्रोग्रामिंग मुहावरा हाल ही में आया हूँ:

const float Zero = 0.0;

जो तब तुलना में प्रयोग किया जाता है:

if (x > Zero) {..}

क्या कोई समझा सकता है कि क्या यह वास्तव में अधिक कुशल या पठनीय है या इसकी तुलना में बनाए रखने योग्य है:

if (x > 0.0) {..}

ध्यान दें: मैं इस निरंतरता को परिभाषित करने के अन्य कारणों के बारे में सोच सकता हूं , मैं इस संदर्भ में इसके उपयोग के बारे में सोच रहा हूं ।

Comments

डेवलपर्स कोड को एक ब्रह्मांड में पोर्ट करने की योजना बना रहे हैं जहां गणित के नियम अलग हैं?

— विघ्नहर्ता

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

— vaughandroid

@ बकेट-एक वैकल्पिक ब्रह्मांड? मुझे लगता है कि वे पहले से ही वहां रहते थे! जादू की संख्या के लिए, मैं सहमत हूं, हालांकि मैं अंगूठे के नियम का उपयोग करता हूं कि 0 और 1 को छोड़कर सब कुछ स्थिर होना चाहिए।

— एनडब्ल्यूएस

यदि xप्रकार है float, तो x > 0.0पदोन्नति को मजबूर करता है double, जो कम कुशल हो सकता है। नामांकित स्थिरांक का उपयोग करने के लिए यह एक अच्छा कारण नहीं है, बस यह सुनिश्चित करने के लिए कि आपके स्थिरांक का सही प्रकार है (उदाहरण के लिए 0f, float(0)या decltype(x)(0))।

— माइक सेमोर

@ जोसो: निष्पक्ष होने के लिए, 13.37ऐसा नहीं है float, यह है double। इसलिए यदि आप चाहते थे floatतो यह अनुमान है कि आपका ट्यूटर सही था। कुछ संदर्भों में (उदाहरण के लिए एक फ्लोट को असाइन करना) 13.37को आप के इच्छित रूप में परिवर्तित कर दिया जाएगा float, और अन्य संदर्भों (जैसे टेम्पलेट प्रकार में कटौती) में यह नहीं होगा, जबकि static const floatहमेशा आपके द्वारा इच्छित प्रकार के रूप में शुरू होता है। इसलिए, अधिक प्रकार-सुरक्षित। तुम मन, तो होगा 13.37f! "टाइप-सेफ्टी" की तुलना में मैक्रो से बचने के अन्य कारण हैं, हालांकि, यह सिर्फ इस बात की संभावना है कि ट्यूटर आपको एक खराब तर्क दे रहा है।

— स्टीव जेसप

Answer 1

संभावित कारण कैशिंग, नामकरण या जबरन प्रकार हैं

कैशिंग (लागू नहीं)

आप तुलना के कार्य के दौरान एक वस्तु बनाने की लागत से बचना चाहते हैं। जावा में एक उदाहरण होगा

BigDecimal zero = new BigDecimal ("0.0");

इसमें एक काफी भारी निर्माण प्रक्रिया शामिल है और प्रदान की गई स्थैतिक विधि का उपयोग करके बेहतर सेवा की जाती है:

BigDecimal zero = BigDecimal.ZERO;

यह सृजन की बार-बार की लागत के बिना तुलना करने की अनुमति देता है क्योंकि बिगडिमल को जेवीएम द्वारा प्रारंभिक जांच के दौरान प्री-कैश किया गया है।

आपके द्वारा वर्णित के मामले में, एक आदिम वही काम कर रहा है। यह कैशिंग और प्रदर्शन के मामले में काफी हद तक बेमानी है।

नामकरण (असंभावित)

मूल डेवलपर पूरे सिस्टम में सामान्य मूल्यों के लिए एक समान नामकरण सम्मेलन प्रदान करने का प्रयास कर रहा है। इसमें कुछ योग्यताएं हैं, विशेष रूप से असामान्य मूल्यों के साथ लेकिन शून्य जैसा बुनियादी कुछ पहले के कैशिंग मामले में केवल इसके लायक है।

मजबूर प्रकार (सबसे अधिक संभावना)

मूल डेवलपर किसी विशेष आदिम प्रकार को यह सुनिश्चित करने का प्रयास कर रहा है कि तुलना उनके सही प्रकार और संभवतः एक विशेष पैमाने (दशमलव स्थानों की संख्या) पर डाली जाए । यह ठीक है, लेकिन सरल नाम "शून्य" शायद इस उपयोग के मामले के लिए अपर्याप्त विस्तार है जिसमें ZERO_1DP इरादे की अधिक उपयुक्त अभिव्यक्ति है।

Comments

मजबूर करने के लिए +1। मैं इसे C ++ जैसी भाषाओं में जोड़ दूंगा जो ऑपरेटर को ओवरलोडिंग की अनुमति देता है, एक निरंतर और उपयोग को परिभाषित करने typedefके लिए चर के प्रकार को एक स्थान पर रखेगा और कोड को बदलने के बिना इसे बदलने में सक्षम करेगा।

— ब्लरफुल

मजबूर प्रकार सबसे अधिक संभावना नहीं है कि वे क्या करने की कोशिश कर रहे थे, हालांकि यह सबसे अच्छा स्पष्टीकरण है कि यह क्यों किया जा सकता है!

— एनडब्ल्यूएस

मजबूर प्रकार के लिए, मैं शायद सिर्फ उपयोग करना चाहता हूं 0.0f।

— शाविश

मजबूर प्रकार कभी-कभी vb.net में उपयोगी हो सकता है, जहां बाइट्स पर बिटवाइज़ ऑपरेटर प्रदर्शन करते हुए एक बाइट परिणाम प्राप्त करते हैं। कहने byteVar1 = byteVar2 Or CB128से थोड़ा अच्छा लगता है byteVar1 = byteVar2 Or CByte(128)। बेशक, बाइट्स के लिए एक उचित संख्यात्मक प्रत्यय होने से अभी तक बेहतर होगा। चूंकि C # ऑपरेटरों को बिटवाइज़ के ऑपरेंड को बढ़ावा देता है, intयहां तक ​​कि जब परिणाम को फिट होने की गारंटी दी जाएगी byte, तो मुद्दा इतना प्रासंगिक नहीं है।

— सुपरकैट

मुझे '0' के लिए ज़ीरो के रूप में निरंतर नाम रखने के बारे में निश्चित नहीं है, लेकिन कभी-कभी यह कोड पठनीयता में मदद करता है; उदाहरण के लिए, शून्य के लिए यह स्थिर रहना - "ROOT_TYPE_ID = 0" यदि (आईडी! ROOT_TYPE_ID) {..}

— टेक जंकी

Answer 2

यह "टूलींग नागिंग" के कारण है

एक संभावित कारण जो मुझे यहां सूचीबद्ध नहीं दिखता है, क्योंकि बहुत सारे गुणवत्ता वाले उपकरण जादू नंबर का उपयोग करते हैं । बाद में बदलाव के लिए स्पष्ट रूप से दिखाई देने के बिना एल्गोरिथ्म में फेंक दिए गए जादू की संख्याओं को रखने के लिए अक्सर एक बुरा अभ्यास होता है , खासकर अगर उन्हें कोड में कई स्थानों पर दोहराया जाता है।

इसलिए, जब ये उपकरण ऐसे मुद्दों को चिह्नित करने के बारे में सही होते हैं, तो वे अक्सर उन स्थितियों के लिए झूठी सकारात्मकता उत्पन्न करते हैं जहां ये मूल्य हानिरहित होते हैं और सबसे अधिक स्थिर होने की संभावना होती है, या केवल आरंभिक मूल्य होते हैं।

और जब ऐसा होता है, तो कभी-कभी आपकी पसंद का सामना करना पड़ता है:

• उन्हें झूठी सकारात्मक के रूप में चिह्नित करना, अगर उपकरण इसे अनुमति देता है (आमतौर पर विशेष रूप से स्वरूपित टिप्पणी के साथ, जो उपकरण का उपयोग नहीं करने वाले लोगों के लिए कष्टप्रद है)
• या स्थिरांक के लिए इन मूल्यों को निकालना, चाहे वह मायने रखता हो या नहीं।

प्रदर्शन के बारे में

यह उस भाषा पर निर्भर करता है जिसका मैं अनुमान लगाता हूं, लेकिन यह जावा में काफी सामान्य है और इसका कोई प्रदर्शन प्रभाव नहीं है, क्योंकि मूल्य वास्तविक समय में संकलित होने पर संकलित होते हैं static final। इसका प्रभाव C या C ++ में नहीं होगा यदि उन्हें स्थिरांक के रूप में या यहां तक ​​कि पूर्व-प्रोसेसर मैक्रोज़ के रूप में घोषित किया जाता है।

Answer 3

यह समझ में आता है क्योंकि यह स्पष्ट रूप Zeroसे प्रकार के लिए परिभाषित करता है float।

कम से कम C और C ++ में मूल्य 0.0प्रकार का है double, जबकि समकक्ष floatहै 0.0f। इसलिए xआपके खिलाफ तुलना करना हमेशा एक floatकहावत है

x > 0.0

जबकि वास्तव में मैच के प्रकार को बढ़ावा देने के xलिए जिनमें से मुद्दों (विशेषकर समानता परीक्षण के साथ) हो सकता है। रूपांतरण के बिना तुलना जरूर होगीdouble0.0

x > 0.0f

जो जैसा करता है वैसा ही करता है

float Zero = 0.0; // double 0.0 converted to float  
x > Zero

फिर भी, मुझे लगता है कि उपयोगकर्ताओं को अजीब कोड लिखने के बजाय संकलक में रूपांतरण की चेतावनी को सक्षम करने के लिए यह अधिक उपयोगी होगा।

Answer 4

सबसे पहले, यहां शून्य को परिभाषित किया गया है float, नहीं int। बेशक, यह तुलना में कुछ भी प्रभावित नहीं करता है, लेकिन अन्य मामलों में जब इस निरंतर का उपयोग किया जाता है, तो इससे अंतर हो सकता है।

मुझे कोई और कारण नहीं दिखता कि मुझे Zeroयहां स्थाई घोषित क्यों किया गया। यह सिर्फ कुछ कोडिंग शैली है, और शैली का पालन करना बेहतर है यदि यह उस निश्चित कार्यक्रम में हर जगह उपयोग किया जाता है।

Answer 5

यह निष्पादन के दौरान लगभग निश्चित रूप से कुशल है (जब तक कि आपका कंपाइलर बहुत आदिम नहीं है) और संकलन के दौरान बहुत कम कुशल।

जैसे कि क्या वह अधिक पठनीय है x > 0... याद रखें कि ऐसे लोग हैं जो ईमानदारी से, वास्तव में, सोचते हैं कि COBOL एक महान विचार था और साथ काम करने के लिए एक खुशी थी - और फिर ऐसे लोग हैं जो सी के बारे में बिल्कुल ऐसा ही सोचते हैं (अफवाह है) यह है कि C ++ के बारे में समान राय वाले कुछ प्रोग्रामर मौजूद हैं। दूसरे शब्दों में, आप इस बिंदु पर सामान्य समझौता नहीं करने जा रहे हैं , और यह शायद लड़ने के लायक नहीं है।

Answer 6

[] यह वास्तव में से अधिक कुशल या पठनीय या बनाए रखने योग्य है:

if (x > 0.0) {..}

यदि आप सामान्य (यानी गैर-प्रकार-विशिष्ट) कोड लिख रहे थे , तो बहुत संभव है। एक zero()फ़ंक्शन किसी भी बीजीय प्रकार, या किसी भी प्रकार पर लागू हो सकता है जो एक समूह राइट जोड़ है। यह एक पूर्णांक हो सकता है, यह एक फ़्लोटिंग-पॉइंट मान हो सकता है, यह एक फ़ंक्शन भी हो सकता है यदि आपका वैरिएबल है, कहो, कुछ रैखिक स्थान के भीतर ही एक फ़ंक्शन (जैसे x प्रपत्र z का एक रैखिक कार्य है -> a_x * z + b_x) और फिर zero()दोनों zero()को अंतर्निहित प्रकार के होने के साथ फ़ंक्शन प्रदान करता है ।

तो आप इस तरह के कोड की उम्मीद करेंगे, कहते हैं, C ++ संभवतः (हालांकि zero()यह बहुत आम AFAIK नहीं है), या जूलिया, और शायद अन्य भाषाओं में।