पूर्णांक का उपयोग करते समय <= और> = से बचना चाहिए, जैसे कि एक लूप में? [बन्द है]

Question

मैंने अपने छात्रों को समझाया है कि फ्लोट चर के लिए बराबर-परीक्षण करना विश्वसनीय नहीं है, लेकिन पूर्णांकों के लिए ठीक है। मैं जिस पाठ्यपुस्तक का उपयोग कर रहा हूं, उसने कहा कि> और <=> और <= को पढ़ना आसान है। मैं कुछ हद तक सहमत हूं, लेकिन फॉर लूप में? क्या यह स्पष्ट नहीं है कि लूप शुरू और समाप्ति मूल्यों को निर्दिष्ट करता है?

क्या मुझे ऐसी कोई चीज़ याद आ रही है जिसके बारे में पाठ्यपुस्तक लेखक सही है?

एक और उदाहरण रेंज परीक्षणों में है जैसे:

अगर स्कोर> 89 ग्रेड = 'ए'
और अगर स्कोर> 79 ग्रेड = 'बी' ...

सिर्फ क्यों नहीं कहा: अगर स्कोर> = 90?

Comments

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

— Ixrec

इससे कोई फर्क नहीं पड़ता। वास्तव में।

— ऑबेरॉन

वास्तव में, यह उद्देश्यपूर्ण उत्तर देने योग्य है। स्टैंड बाय ...

— रॉबर्ट हार्वे

@Ixrec मुझे हमेशा यह दिलचस्प लगता है कि "सबसे अच्छा अभ्यास" एक उपयुक्त विषय नहीं माना जाता है। कौन अपने कोड को बेहतर नहीं बनाना चाहता है, या अपने कोड को अधिक पठनीय बनाना चाहता है? यदि लोग असहमत हैं, तो हम सभी इस मुद्दे के अधिक पक्ष सीखते हैं, और हो सकता है ... यहां तक ​​कि ... परिवर्तन-हमारा-मन! उह, यह कहना बहुत कठिन था। रॉबर्ट हार्वे का कहना है कि वह इसका उत्तर निष्पक्ष रूप से दे सकते हैं। यह दिलचस्प होगा।

@nocomprende ज्यादातर क्योंकि "सर्वश्रेष्ठ अभ्यास" एक अत्यंत अस्पष्ट और अति प्रयोग किया जाने वाला शब्द है, जो भाषा के बारे में वस्तुनिष्ठ तथ्यों के आधार पर उपयोगी सलाह दे सकता है , लेकिन जैसा कि अक्सर "सबसे लोकप्रिय राय" (या जो कोई भी इस शब्द का उपयोग कर रहा है) की राय को संदर्भित करता है जब वास्तव में सभी विकल्प समान रूप से मान्य और अमान्य हैं। इस मामले में, आप केवल कुछ प्रकार के छोरों के उत्तर को प्रतिबंधित करके एक उद्देश्य तर्क कर सकते हैं जैसा कि रॉबर्ट ने किया था, और जैसा कि आपने खुद को एक टिप्पणी में इंगित किया है जो सवाल का पूरी तरह से जवाब नहीं देता है।

— Ixrec

Answer 1

शून्य-आधारित सरणियों के साथ घुंघराले-लटके प्रोग्रामिंग भाषाओं में for, इस तरह से लूप लिखने की प्रथा है :

for (int i = 0; i < array.Length, i++) { }

यह सरणी में सभी तत्वों का पता लगाता है, और अब तक का सबसे आम मामला है। यह <=या के उपयोग से बचा जाता है >=।

यह केवल कभी-कभी बदलना होगा जब आपको पहले या अंतिम तत्व को छोड़ना होगा, या इसे विपरीत दिशा में ले जाना होगा, या इसे एक अलग शुरुआत बिंदु से या एक अलग अंत बिंदु तक ले जाना होगा।

संग्रह के लिए, भाषाओं में जो पुनरावृत्तियों का समर्थन करते हैं, यह देखना अधिक आम है:

foreach (var item in list) { }

जो पूरी तरह से तुलना से बचता है।

यदि आप एक कठिन और तेज नियम की तलाश कर रहे हैं , जब <=बनाम का उपयोग करना है <, तो एक नहीं है; वह प्रयोग करें जो आपके इरादे को सबसे अच्छा व्यक्त करता है। यदि आपके कोड को "55 मील प्रति घंटे से कम या बराबर" अवधारणा को व्यक्त करने की आवश्यकता है, तो यह कहने की आवश्यकता है <=, नहीं <।

ग्रेड सीमाओं के बारे में आपके प्रश्न का उत्तर देने के लिए, >= 90अधिक समझ में आता है, क्योंकि 90 वास्तविक सीमा मूल्य है, न कि 89।

Comments

यह पूरी तरह से तुलना से परहेज नहीं करता है, यह बस उन्हें रगड़ के तहत उन्हें एन्यूमरेटर कार्यान्वयन में स्थानांतरित करता है। : पी

— मेसन व्हीलर

बेशक, लेकिन यह अब एक सरणी नहीं है, यह है?

— रॉबर्ट हार्वे

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

— रॉबर्ट हार्वे

"उपयोग करें जो आपके इरादे को सबसे अच्छा व्यक्त करता है" <- यह!

— जैस्पर एन। ब्रूवर

@ JasperN.Brouwer यह प्रोग्रामिंग के शून्य कानून की तरह है। सभी नियम और कोडिंग रूढ़ियां सबसे ज्यादा शर्म की बात है जब उनके कोड की स्पष्टता के साथ संघर्ष होता है।

— इविलनोटिक्सिस्ट इडोनाटेक्सिस्ट

Answer 2

इससे कोई फर्क नहीं पड़ता।

लेकिन तर्क के लिए, चलो दो विकल्पों का विश्लेषण करते हैं: a > bबनाम a >= b।

डटे रहो! वे समकक्ष नहीं हैं!
ठीक है, फिर a >= b -1बनाम a > bया a > bबनाम a >= b +1।

हम्म, a >bऔर a >= bदोनों की तुलना में बेहतर दिखते हैं a >= b - 1और a >= b +1। 1वैसे भी ये सब क्या हैं ? इसलिए मेरा तर्क है कि >इसके बजाय >=या इसके विपरीत होने से कोई लाभ यादृच्छिक 1एस को जोड़ने या घटाने के द्वारा समाप्त हो गया है ।

लेकिन अगर यह एक संख्या है तो क्या होगा? यह कहना बेहतर है a > 7या a >= 6? एक सेकंड रुको। क्या हम गंभीरता से इस बात पर बहस कर रहे हैं कि क्या >बनाम उपयोग करने के लिए बेहतर है >=और हार्ड कोडित चर को अनदेखा करना है? तो यह वास्तव में एक सवाल बन जाता है कि क्या इससे a > DAYS_OF_WEEKबेहतर है a >= DAYS_OF_WEEK_MINUS_ONE... या यह a > NUMBER_OF_LEGS_IN_INSECT_PLUS_ONEबनाम है a >= NUMBER_OF_LEGS_IN_INSECT? और हम वापस जोड़ने / घटाना 1एस, केवल इस बार चर नामों में। या हो सकता है कि अगर यह दहलीज, सीमा, अधिकतम का उपयोग करने के लिए सबसे अच्छा है।

और ऐसा लगता है कि कोई सामान्य नियम नहीं है: यह इस बात पर निर्भर करता है कि क्या तुलना की जा रही है

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

Comments

ठीक है, कोई सामान्य नियम नहीं है। (आश्चर्य है कि पाठ्यपुस्तक एक सामान्य नियम क्यों बताती है, लेकिन मैं इसे जाने दे सकता हूं।) इस बात पर कोई सहमति नहीं है कि यह एक ऐसा ज्ञापन था जिसे मैंने याद किया।

@nocomprende क्योंकि कोडिंग और प्रारूपण मानक दोनों विशुद्ध रूप से व्यक्तिपरक और अत्यधिक विवादास्पद हैं। अधिकांश समय उनमें से कोई भी मायने नहीं रखता है, लेकिन प्रोग्रामर अभी भी उन पर पवित्र युद्ध करते हैं। (वे केवल तब ही बात करते हैं जब मैला कोड के परिणामस्वरूप कीड़े होने की संभावना होती है)

मैंने कोडिंग मानकों के बारे में बहुत सारे पागल चर्चाएं देखी हैं, लेकिन यह सिर्फ केक ले सकता है। वास्तव में मूर्खतापूर्ण।

— जिम्मीजाम्स

@JimmyJames यह >बनाम >=की चर्चा या इस बारे में चर्चा है कि क्या >बनाम की चर्चा >=सार्थक है? हालाँकि इस पर चर्चा करने से बचना शायद सबसे अच्छा है: p

— थानोस टिंटिनिडिस

"कार्यक्रम मनुष्यों द्वारा पढ़ा जाता है और केवल संयोगवश कंप्यूटर को निष्पादित करने के लिए होता है" - डोनाल्ड नुथ। शैली का उपयोग करें जो पढ़ने, समझने और बनाए रखने में आसान बनाता है।

— सिंपलसर

Answer 3

Computationally वहाँ का उपयोग करते समय लागत में कोई अंतर नहीं है <या >की तुलना में <=या >=। इसकी गणना उतनी ही तेजी से की जाती है।

हालाँकि, लूप के लिए अधिकांश की गिनती 0 से की जाएगी (क्योंकि कई भाषाएं अपने सरणियों के लिए 0 अनुक्रमण का उपयोग करती हैं)। तो उन भाषाओं में लूप के लिए विहित है

for(int i = 0; i < length; i++){
   array[i] = //...
   //...
}

ऐसा <=करने से आपको ऑफ-वन त्रुटि से बचने के लिए कहीं न कहीं -1 जोड़ना होगा

for(int i = 1; i <= length; i++){
   array[i-1] = //...
   //...
}

या

for(int i = 0; i <= length-1; i++){
   array[i] = //...
   //...
}

बेशक अगर भाषा 1-आधारित अनुक्रमण का उपयोग करती है तो आप सीमित स्थिति के रूप में <= का उपयोग करेंगे।

कुंजी यह है कि स्थिति में व्यक्त मूल्य समस्या वर्णन से हैं। यह पढ़ने के लिए क्लीनर है

if(x >= 10 && x < 20){

} else if(x >= 20 && x < 30){

}

से आधे खुले अंतराल के लिए

if(x >= 10 && x <= 19){

} else if(x >= 20 && x <= 29){

}

और यह जानने के लिए गणित करना होगा कि 19 और 20 के बीच कोई संभावित मूल्य नहीं है

Comments

मैं "लंबाई" विचार देखता हूं, लेकिन क्या होगा यदि आप केवल उन मूल्यों का उपयोग कर रहे हैं जो कहीं से आए थे और एक शुरुआती मूल्य से एक अंतिम मूल्य तक पहुंचने के लिए हैं। एक वर्ग उदाहरण 5 से 10 तक मार्कअप प्रतिशत था। क्या यह कहना स्पष्ट नहीं है: (मार्कअप = 5; मार्क <= 10; मार्कअप ++) के लिए ... ? : क्यों मैं इसे करने के लिए परीक्षण बदल जाएगा मार्कअप <11 ?

@nocomprende आप नहीं करेंगे, यदि आपके समस्या वर्णन के सीमा मान 5 और 10 हैं, तो कोड में थोड़े बदले हुए मूल्य के बजाय उन्हें स्पष्ट रूप से रखना बेहतर है।

— शाफ़्ट

@nocomprende सही प्रारूप अधिक स्पष्ट है जब ऊपरी सीमा एक पैरामीटर है for(markup = 5; markup <= MAX_MARKUP; ++markup):। और कुछ भी यह overcomplicating होगा।

— नवीन

Answer 4

मैं कहूंगा कि बिंदु यह नहीं है कि क्या आपको> या> = का उपयोग करना चाहिए। मुद्दा यह है कि आप अभिव्यंजक कोड लिखने की अनुमति दें।

यदि आप पाते हैं कि आपको एक को जोड़ना / घटाना है, तो दूसरे ऑपरेटर का उपयोग करने पर विचार करें। मुझे लगता है कि अच्छी चीजें तब होती हैं जब आप अपने डोमेन के एक अच्छे मॉडल के साथ शुरुआत करते हैं। फिर तर्क खुद लिखता है।

bool IsSpeeding(int kilometersPerHour)
{
    const int speedLimit = 90;
    return kilometersPerHour > speedLimit;
}

इस तरह से अधिक अभिव्यंजक है

bool IsSpeeding(int kilometersPerHour)
{
    const int speedLimit = 90;
    return kilometersPerHour >= (speedLimit + 1);
}

अन्य मामलों में, दूसरा तरीका बेहतर है:

bool CanAfford(decimal price, decimal balance)
{
    return balance >= price;
}

उससे काफी बेहतर

bool CanAfford(decimal price, decimal balance)
{
    const decimal epsilon = 0e-10m;
    return balance > (price - epsilon);
}

कृपया "आदिम जुनून" का बहाना करें। जाहिर है कि आप क्रमशः यहां एक वेग- और धन-प्रकार का उपयोग करना चाहेंगे, लेकिन मैंने उन्हें संक्षिप्तता के लिए छोड़ दिया। मुद्दा यह है: उस संस्करण का उपयोग करें जो अधिक संक्षिप्त है और इससे आप उस व्यावसायिक समस्या पर ध्यान केंद्रित कर सकते हैं जिसे आप हल करना चाहते हैं।

Comments

गति सीमा उदाहरण एक खराब उदाहरण है। एक 90kph क्षेत्र में 90kph जाना गतिमान नहीं माना जाता है। एक गति सीमा समावेशी है।

— Eidsonator

आप बिल्कुल सही हैं, मेरी ओर से मस्तिष्क गला। बेहतर उदाहरण का उपयोग करने के लिए इसे संपादित करने के लिए स्वतंत्र महसूस करें, उम्मीद है कि बिंदु पूरी तरह से खो नहीं गया है।

— सारा

Answer 5

जैसा कि आपने अपने प्रश्न में बताया है, फ्लोट चर पर समानता के लिए परीक्षण विश्वसनीय नहीं है।

वही धारण करता है <=और के लिए सच है >=।

हालाँकि, पूर्णांक प्रकारों के लिए ऐसी कोई विश्वसनीयता समस्या नहीं है। मेरी राय में, लेखक अपनी राय व्यक्त कर रहा था, जो अधिक पठनीय है।

आप उससे सहमत हैं या नहीं, निश्चित रूप से आपकी राय है।

Comments

क्या यह आम तौर पर दूसरे लेखकों द्वारा और मैदान में ग्रे-बाल (मेरे पास ग्रे बाल हैं, वास्तव में) है? अगर यह सिर्फ "एक रिपोर्टर की राय" है, तो मैं छात्रों को बता सकता हूं। मेरे पास वास्तव में है। इस विचार के बारे में पहले कभी नहीं सुना।

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

— डेन पिचेलमैन

सहमत नहीं हैं। वहाँ कर सकते हैं पूर्णांक प्रकार के साथ विश्वसनीयता मुद्दों हो: सी में, पर विचार करें: for (unsigned int i = n; i >= 0; i--)या for (unsigned int i = x; i <= y; i++)अगर yहोता है UINT_MAX। उफ़, उन पाश हमेशा के लिए।

— jamesdlin

Answer 6

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

मैं उन मामलों के लिए उदाहरण देता हूँ जहाँ आप उनमें से प्रत्येक के लिए यही ऑपरेटर चाहते हैं। (NaNs से अवगत रहें, हालाँकि)

• आपके पास एक महंगा शुद्ध कार्य है f जो इनपुट के रूप में फ्लोटिंग-पॉइंट वैल्यू लेता है। अपनी गणना को गति देने के लिए, आप सबसे हाल ही में गणना किए गए मानों का एक कैश जोड़ने का निर्णय लेते हैं, जो कि एक लुकअप टेबल टैपिंग xहै f(x)। आप वास्तव ==में तर्कों की तुलना करना चाहते हैं ।
• आप जानना चाहते हैं कि क्या आप सार्थक रूप से कुछ संख्या से विभाजित कर सकते हैं x? आप शायद उपयोग करना चाहते हैं x != 0.0।
• आप जानना चाहते हैं कि क्या xयूनिट अंतराल में कोई मूल्य है? (x >= 0.0) && (x < 1.0)सही स्थिति है।
• आपने निर्धारक की गणना की है d मैट्रिक्स की और यह बताना चाहते हैं कि क्या यह सकारात्मक निश्चित है? कुछ और उपयोग करने का कोई कारण नहीं है लेकिन d > 0.0।
• आप जानना चाहते हैं कि क्या _{= n = 1,…, −} n ^verα विचलन? मैं के लिए परीक्षण करेंगेalpha <= 1.0 ।

फ्लोटिंग-पॉइंट गणित (सामान्य रूप में) सटीक नहीं है। लेकिन इसका मतलब यह नहीं है कि आपको इसे डरना चाहिए, इसे जादू के रूप में मानें, और निश्चित रूप से हमेशा दो फ्लोटिंग-पॉइंट मात्राओं के बराबर व्यवहार न करें यदि वे भीतर हैं 1.0E-10। ऐसा करना वास्तव में होगा आपका गणित टूट और सभी अजीब चीजें घटित होंगी।

• उदाहरण के लिए, यदि आप ऊपर उल्लिखित कैश के साथ फजी तुलना का उपयोग करते हैं, तो आप उल्लसित त्रुटियों का परिचय देंगे। लेकिन इससे भी बदतर, फ़ंक्शन अब शुद्ध नहीं होगा और त्रुटि पहले गणना किए गए परिणामों पर निर्भर करती है!
• हाँ, भले ही x != 0.0और yएक फ़्लोटिंग फ़्लोटिंग-पॉइंट वैल्यू हो, y / xफ़ाइनिट होने की आवश्यकता नहीं है। लेकिन यह जानना प्रासंगिक हो सकता है कि क्या y / xअतिप्रवाह के कारण परिमित नहीं है या क्योंकि ऑपरेशन शुरू करने के लिए गणितीय रूप से अच्छी तरह से परिभाषित नहीं था।
• आप एक समारोह एक पूर्व शर्त है कि एक इनपुट पैरामीटर के रूप में है कि है, तो xइकाई अंतराल [0, 1 में हो गया है), मैं वास्तव में परेशान किया जाएगा अगर यह एक अभिकथन विफलता जब साथ बुलाया निकाल दिया x == 0.0या x == 1.0 - 1.0E-14।
• आपके द्वारा निर्धारित किया गया निर्धारक सटीक नहीं हो सकता है। लेकिन अगर आप यह ढोंग करने जा रहे हैं कि मैट्रिक्स सकारात्मक निश्चित नहीं है जब गणना निर्धारक है 1.0E-30, तो कुछ भी प्राप्त नहीं होता है। आपने जो किया वह गलत उत्तर देने की संभावना को बढ़ा रहा था ।
• हां, आपका तर्क alphaराउंडिंग त्रुटियों से प्रभावित हो सकता है और इसलिए alpha <= 1.0यह सच भी हो सकता है, हालांकि अभिव्यक्ति के लिए सही गणितीय मूल्य alphaकी गणना सही मायने में 1 से अधिक हो सकती है। लेकिन इस बिंदु पर आप संभवतः इसके बारे में कुछ भी नहीं कर सकते हैं।

हमेशा की तरह सॉफ्टवेयर इंजीनियरिंग में, उचित स्तर पर त्रुटियों को संभालना और उन्हें केवल एक बार संभालना। यदि आप के आदेश पर गोलाई की त्रुटियां जोड़ते हैं 1.0E-10(ऐसा लगता है कि अधिकांश लोग इसका उपयोग करते हैं, तो मुझे नहीं पता कि क्यों) हर बार जब आप फ्लोटिंग-पॉइंट मात्रा की तुलना कर रहे हैं, तो आप जल्द ही के आदेश पर त्रुटियों में होंगे 1.0E+10...

Comments

एक सबसे उत्कृष्ट जवाब, हालांकि स्वीकार किया जाता है, केवल एक अलग प्रश्न के लिए जो पूछा गया है।

— डेवी मॉर्गन

Answer 7

एक लूप में प्रयुक्त सशर्त का प्रकार बेहतर या बदतर के लिए संकलक के अनुकूलन के प्रकारों को सीमित कर सकता है। उदाहरण के लिए, दिया गया:

uint16_t n = ...;
for (uint16_t i=1; i<=n; i++)
  ...  [loop doesn't modify i]

एक संकलक मान सकता है कि उपरोक्त स्थिति के कारण लूप को nth पास लूप के बाद बाहर निकलने का कारण बनना चाहिए जब तक कि n 65535 नहीं हो सकता है और लूप n से अधिक होने के अलावा कुछ फैशन में बाहर निकल सकता है। यदि वे स्थितियां लागू होती हैं, तो संकलक को कोड उत्पन्न करना होगा जो लूप को चलाने के लिए तब तक चलेगा जब तक कि उपरोक्त स्थिति के अलावा कुछ और बाहर निकलने का कारण न हो।

यदि लूप को इसके बजाय लिखा गया था:

uint16_t n = ...;
for (uint16_t ctr=0; ctr<n; ctr++)
{
  uint16_t i = ctr+1;
  ... [loop doesn't modify ctr]
}

तब एक संकलक सुरक्षित रूप से मान सकता है कि लूप को कभी-कभी n से अधिक बार निष्पादित करने की आवश्यकता नहीं होगी और इस प्रकार अधिक कुशल कोड उत्पन्न करने में सक्षम हो सकता है।

ध्यान दें कि हस्ताक्षरित प्रकारों के साथ किसी भी अतिप्रवाह में बुरा परिणाम हो सकता है। दिया हुआ:

int total=0;
int start,lim,mult; // Initialize values somehow...
for (int i=start; i<=lim; i++)
  total+=i*mult;

एक कंपाइलर फिर से लिख सकता है:

int total=0;
int start,lim,mult; // Initialize values somehow...
int loop_top = lim*mult;
for (int i=start; i<=loop_top; i+=mult)
  total+=i;

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

Comments

हाँ, मुझे लगता है कि यह पाठ्यपुस्तक में थोड़ा आगे है। अभी विचार नहीं हुआ। कंपाइलर ऑप्टिमाइज़ेशन समझने के लिए उपयोगी होते हैं, और ओवरफ्लो से बचना पड़ता है, लेकिन यह वास्तव में मेरे प्रश्न की प्रेरणा नहीं थी, जो लोगों के कोड को समझने के संदर्भ में अधिक थी। क्या x> 5 या x> = 6 पढ़ना आसान है? खैर, यह निर्भर करता है ...

जब तक आप एक Arduino के लिए नहीं लिख रहे हैं इंट के लिए अधिकतम मूल्य 65535 से थोड़ा अधिक होने वाला है।

— कोरी

@ कोरी: uint16_t के लिए अधिकतम मूल्य किसी भी मंच पर 65535 होने जा रहा है जहां प्रकार मौजूद है; मैंने पहले उदाहरण में uint16_t का उपयोग किया क्योंकि मैं अधिक लोगों से uint16_t के सटीक अधिकतम मूल्य को जानने की अपेक्षा करूंगा। दोनों मामलों में एक ही बिंदु लागू होगा। दूसरा उदाहरण "इंट" के प्रकार के संबंध में अज्ञेयवादी है, और एक महत्वपूर्ण व्यवहार बिंदु का प्रतिनिधित्व करता है कई लोग अन्य संकलक के बारे में पहचानने में विफल होते हैं।

— सुपरकाट