C और C ++ में अहस्ताक्षरित पूर्णांक का उपयोग करना

Question

मेरे पास एक बहुत ही सरल प्रश्न है जो मुझे लंबे समय तक चकरा देता है। मैं नेटवर्क और डेटाबेस के साथ काम कर रहा हूं इसलिए बहुत से डेटा जो मैं काम कर रहा हूं 32-बिट और 64-बिट काउंटर (अहस्ताक्षरित), 32-बिट और 64-बिट पहचान आईडी (साइन के लिए सार्थक मैपिंग नहीं है)। मैं व्यावहारिक रूप से कभी भी किसी भी वास्तविक शब्द मामले से नहीं निपटता हूं जिसे नकारात्मक संख्या के रूप में व्यक्त किया जा सकता है।

मैं और मेरे सह-कार्यकर्ता नियमित रूप से इन मामलों के लिए uint32_tऔर जैसे अनियोजित प्रकारों का उपयोग uint64_tकरते हैं और ऐसा इसलिए होता है क्योंकि अक्सर हम उनका उपयोग सरणी अनुक्रमित और अन्य सामान्य पूर्णांक उपयोगों के लिए भी करते हैं।

उसी समय विभिन्न कोडिंग गाइड जो मैं पढ़ रहा हूं (उदाहरण के लिए Google) अहस्ताक्षरित पूर्णांक प्रकारों के उपयोग को हतोत्साहित करता हूं, और जहां तक ​​मुझे पता है कि न तो जावा और न ही स्काला में अहस्ताक्षरित पूर्णांक प्रकार हैं।

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

Comments

संबंधित: क्या पूर्णांक का उपयोग डेटा प्रकार के रूप में बहुत अधिक किया जाता है?

— जन्नत

Answer 1

इस पर विचार के दो स्कूल हैं, और न ही कभी सहमत होंगे।

पहले का तर्क है कि कुछ अवधारणाएं हैं जो स्वाभाविक रूप से अहस्ताक्षरित हैं - जैसे कि सरणी सूचकांक। यह उन लोगों के लिए हस्ताक्षरित संख्याओं का उपयोग करने के लिए कोई मतलब नहीं है क्योंकि यह त्रुटियों को जन्म दे सकता है। यह चीजों पर गैर-आवश्यक सीमाएं भी लगा सकता है - एक सरणी जो हस्ताक्षरित 32-बिट इंडेक्स का उपयोग करता है, केवल 2 बिलियन प्रविष्टियों तक पहुंच सकता है, जबकि अहस्ताक्षरित 32-बिट संख्या पर स्विच करने से 4 बिलियन प्रविष्टियों की अनुमति मिलती है।

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

Comments

संकलक द्वारा मिश्रित हस्ताक्षरित-अहस्ताक्षरित अंकगणित मुद्दों का पता लगाया जाता है; बस अपना बिल्ड वार्निंग-फ्री (उच्च पर्याप्त चेतावनी स्तर के साथ) रखें। इसके अलावा, intटाइप करने के लिए छोटा है :)

— rucamzu

स्वीकारोक्ति: मैं विचार के दूसरे स्कूल के साथ हूं, और हालांकि मैं अहस्ताक्षरित प्रकारों के लिए समझ में आता हूं: int99.99% बार सरणी अनुक्रमित के लिए पर्याप्त से अधिक है। हस्ताक्षरित - अहस्ताक्षरित अंकगणितीय मुद्दे कहीं अधिक सामान्य हैं, और इस तरह से बचने के लिए पूर्वता है। हाँ, संकलक आपको इस बारे में चेतावनी देते हैं, लेकिन किसी भी बड़े प्रोजेक्ट को संकलित करते समय आपको कितनी चेतावनियाँ मिलती हैं? चेतावनी को नजरअंदाज करना खतरनाक और बुरा व्यवहार है, लेकिन वास्तविक दुनिया में ...

— इलायस वान ओटगेम

जवाब देने के लिए +1। सावधानी : ब्लंट ओपिनियन आगे : 1: मेरे विचार के दूसरे स्कूल में मेरी प्रतिक्रिया है: मैं शर्त लगाता हूं कि जो कोई भी सी में अहस्ताक्षरित अभिन्न प्रकार से अप्रत्याशित परिणाम प्राप्त करता है, उसके पास अपरिभाषित व्यवहार होगा (और विशुद्ध रूप से शैक्षणिक प्रकार नहीं) उनके गैर-तुच्छ सी प्रोग्राम जो हस्ताक्षरित अभिन्न प्रकारों का उपयोग करते हैं। यदि आप सी को अच्छी तरह से नहीं जानते हैं कि यह सोचने के लिए कि अहस्ताक्षरित प्रकार का उपयोग करने के लिए बेहतर हैं, मैं सी। 2 से बचने की सलाह देता हूं: सी में अनुक्रमित अनुक्रमित और आकारों के लिए बिल्कुल सही प्रकार है, और size_tजब तक कि कोई विशेष मामला न हो अच्छा कारण है अन्यथा।

— mtraceur

आप मिश्रित हस्ताक्षर के बिना मुसीबत में दौड़ते हैं। बस अहस्ताक्षरित int शून्य अहस्ताक्षरित int की गणना करें।

— gnasher729

अपने साथ सिमोन को नहीं ले जाना, केवल पहले विचार के स्कूल के साथ तर्क है कि "कुछ अवधारणाएं हैं जो स्वाभाविक रूप से अहस्ताक्षरित हैं - जैसे कि सरणी सूचकांक।" विशेष रूप से: "एरे इंडेक्स के लिए एक सही प्रकार है ... सी में," बुलशिट! । हम DSPers हर समय नकारात्मक सूचकांकों का उपयोग करते हैं। विशेष रूप से भी या विषम-समरूपता आवेग प्रतिक्रियाओं के साथ जो गैर-कारण हैं। और गणित के लिए। मैं विचार के दूसरे स्कूल में हूँ, लेकिन मुझे लगता है कि यह C और C ++ में हस्ताक्षरित और अहस्ताक्षरित दोनों के लिए उपयोगी है ।

— रोबर्ट ब्रिस्टो-जॉनसन

Answer 2

सबसे पहले, Google C ++ कोडिंग गाइडलाइन का पालन करने के लिए बहुत अच्छा नहीं है: यह अपवादों, बढ़ावा आदि जैसी चीजों को दूर करता है जो आधुनिक C ++ के स्टेपल हैं। दूसरे, सिर्फ इसलिए कि कंपनी एक्स के लिए एक निश्चित दिशानिर्देश काम करता है इसका मतलब यह नहीं है कि यह आपके लिए सही फिट होगा। मैं अहस्ताक्षरित प्रकारों का उपयोग करना जारी रखूंगा, क्योंकि आपको उनके लिए एक अच्छी आवश्यकता है।

C ++ के लिए अंगूठे का एक सभ्य नियम है: पसंद करें intजब तक कि आपके पास कुछ और उपयोग करने का एक अच्छा कारण न हो।

Comments

यही मेरा मतलब नहीं है। कंस्ट्रक्टर्स इनवेरिएंट्स की स्थापना के लिए हैं, और चूंकि वे फ़ंक्शन नहीं हैं, इसलिए वे बस नहीं कर सकते हैं return falseअगर उस इन्वर्टर को स्थापित नहीं किया गया है। तो, आप या तो चीजों को अलग कर सकते हैं और अपनी वस्तुओं के लिए init फ़ंक्शंस का उपयोग कर सकते हैं, या आप एक फेंक सकते हैं std::runtime_error, स्टैक अनइंडिंग हो सकते हैं, और अपनी सभी RAII ऑब्जेक्ट्स को स्वयं साफ कर सकते हैं और डेवलपर उस अपवाद को संभाल सकते हैं जहां यह सुविधाजनक है आप ऐसा करने के लिए।

— 15

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

— बस्तामौर

मुझे अत्यधिक संदेह है कि सभी C ++ प्रोग्रामर में से आधे अपवादों को ठीक से उपयोग करने में असमर्थ हैं। लेकिन वैसे भी अगर आपको लगता है कि आपके सहकर्मी आधुनिक C ++ लिखने में असमर्थ हैं तो हर तरह से आधुनिक C ++ से दूर रहेंगे।

— 14

@ zzz777 अपवादों का उपयोग न करें? क्या निजी निर्माणकर्ता जो सार्वजनिक कारखाने के कामों के रैपर हैं, जो अपवादों को पकड़ते हैं और क्या करते हैं nullptr? "डिफ़ॉल्ट" ऑब्जेक्ट लौटाएं (जो भी इसका मतलब हो सकता है)? आपने कुछ भी हल नहीं किया है - आपने सिर्फ एक कालीन के नीचे समस्या को छिपाया है, और आशा है कि किसी को पता नहीं चलेगा।

— Mael

@ zzz777 अगर आप किसी भी तरह से बॉक्स को क्रैश करने जा रहे हैं, तो आपको परवाह क्यों है अगर यह अपवाद से होता है या signal(6)? यदि आप एक अपवाद का उपयोग करते हैं, तो 50% डेवलपर्स जो जानते हैं कि उनके साथ कैसे व्यवहार किया जाता है, अच्छा कोड लिख सकते हैं, और बाकी अपने साथियों द्वारा ले जा सकते हैं।

— इल्युसिवब्रियन

Answer 3

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

एक सरणी सूचकांक के रूप में standard size_t का उपयोग करने पर विचार करें:

for (size_t i = 0; i < n; ++i)
    // do something here;

ठीक है, बिल्कुल सामान्य। फिर, विचार करें कि हमने किसी कारण से लूप की दिशा बदलने का फैसला किया है:

for (size_t i = n - 1; i >= 0; --i)
    // do something here;

और अब यह काम नहीं करता है। यदि हम intएक पुनरावृत्त के रूप में उपयोग करते हैं, तो कोई समस्या नहीं होगी। मैंने पिछले दो वर्षों में दो बार ऐसी त्रुटि देखी है। एक बार यह उत्पादन में हुआ और डिबग करना कठिन था।

मेरे लिए एक और कारण कष्टप्रद चेतावनी है, जो आपको हर बार कुछ इस तरह से लिखते हैं :

int n = 123;  // for some reason n is signed
...
for (size_t i = 0; i < size_t(n); ++i)

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

संपादित करें: निश्चित रूप से, उदाहरण गूंगे दिखते हैं, लेकिन मैंने देखा कि लोग यह गलती कर रहे हैं। यदि इससे बचने का इतना आसान तरीका है, तो इसका उपयोग क्यों न करें?

जब मैं VS2015 या GCC के साथ निम्नलिखित कोड को संकलित करता हूं तो मुझे डिफ़ॉल्ट चेतावनी सेटिंग्स (यहां तक ​​कि GCC के लिए -Wall) के साथ कोई चेतावनी नहीं दिखाई देती है। आपको GCC में इस बारे में चेतावनी पाने के लिए -Wextra के लिए पूछना होगा। यह उन कारणों में से एक है जिन्हें आपको हमेशा वॉल और वेक्सट्रा (और स्थिर विश्लेषक का उपयोग करना) के साथ संकलित करना चाहिए, लेकिन कई वास्तविक जीवन परियोजनाओं में लोग ऐसा नहीं करते हैं।

#include <vector>
#include <iostream>


void unsignedTest()
{
    std::vector<int> v{ 1, 2 };

    for (int i = v.size() - 1; i >= 0; --i)
        std::cout << v[i] << std::endl;

    for (size_t i = v.size() - 1; i >= 0; --i)
        std::cout << v[i] << std::endl;
}

int main()
{
    unsignedTest();
    return 0;
}

Comments

आप इसे हस्ताक्षरित प्रकारों के साथ और भी गलत कर सकते हैं ... और आपका उदाहरण-कोड इतना मस्तिष्क-मृत है और गलत तरीके से कोई भी सभ्य संकलक चेतावनी देगा यदि आप चेतावनी मांगते हैं।

— Deduplicator

मैंने अतीत में इस तरह की भयावहता का सहारा लिया for (size_t i = n - 1; i < n; --i)है ताकि यह सही हो सके।

— साइमन बी

size_tरिवर्स -फॉर-लूप की बात करें , तो स्टाइल में एक कोडिंग गाइडलाइन हैfor (size_t revind = 0u; revind < n; ++revind) { size_t ind = n - 1u - revind; func(ind); }

— rwong

@ श्रंग ओमग, यह बदसूरत है। सिर्फ उपयोग क्यों नहीं int? :)

— अलेक्सी पेट्रेंको

@AlexeyPetrenko - ध्यान दें कि न तो वर्तमान सी और न ही सी + + मानकों की गारंटी है जो intसभी वैध मूल्यों को धारण करने के लिए पर्याप्त है size_t। विशेष रूप से, intकेवल 2 ^ 15-1 तक संख्या की अनुमति दे सकते हैं, और आमतौर पर सिस्टम पर ऐसा होता है जिसमें 2 ^ 16 की मेमोरी आवंटन सीमा होती है (या कुछ मामलों में इससे भी अधिक)। longएक सुरक्षित शर्त हो सकती है, हालांकि अभी भी काम करने की गारंटी नहीं है । केवल size_tसभी प्लेटफार्मों पर और सभी मामलों में काम करने की गारंटी है।

— जूल्स

Answer 4

for (size_t i = v.size() - 1; i >= 0; --i)
   std::cout << v[i] << std::endl;

यहां समस्या यह है कि आपने लूप को एक अनचाही तरीके से लिखा है जिससे गलत व्यवहार हो रहा है। लूप का निर्माण शुरुआती की तरह है जो इसे हस्ताक्षरित प्रकारों के लिए सिखाया जाता है (जो ठीक है और सही है) लेकिन यह केवल अहस्ताक्षरित मूल्यों के लिए फिट नहीं है। लेकिन यह अहस्ताक्षरित प्रकारों का उपयोग करने के खिलाफ एक काउंटर तर्क के रूप में काम नहीं कर सकता है, यहाँ कार्य केवल अपने पाश को सही करना है। और यह आसानी से तय किए गए प्रकारों के लिए मज़बूती से काम करने के लिए तय किया जा सकता है:

for (size_t i = v.size(); i-- > 0; )
    std::cout << v[i] << std::endl;

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

size_t i = v.size();
while (i > 0)
{
    --i;
    std::cout << v[i] << std::endl;
}

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

मैं भाग्यशाली होगा यदि शुरुआती पाठ्यक्रम न केवल हस्ताक्षरित के लिए सही लूप दिखाएगा, बल्कि अहस्ताक्षरित प्रकारों के लिए भी होगा। यह दो प्रकार की त्रुटियों से बचना चाहिए जो IM अहस्ताक्षरित डेवलपर्स को अहस्ताक्षरित प्रकार को दोष देने के बजाय दोषी ठहराया जाना चाहिए।

HTH

Answer 5

अनइंस्टॉल किए गए पूर्णांक एक कारण से हैं।

उदाहरण के लिए, व्यक्तिगत बाइट्स के रूप में डेटा सौंपना, उदाहरण के लिए एक नेटवर्क पैकेट या फ़ाइल बफर में। आप कभी-कभी ऐसे जानवरों को 24-बिट पूर्णांक के रूप में सामना कर सकते हैं। आसानी से तीन 8-बिट अहस्ताक्षरित पूर्णांक से स्थानांतरित कर दिया, 8-बिट हस्ताक्षरित पूर्णांक के साथ इतना आसान नहीं है।

या वर्ण लुकअप तालिकाओं का उपयोग करके एल्गोरिदम के बारे में सोचें। यदि कोई वर्ण 8-बिट अहस्ताक्षरित पूर्णांक है, तो आप वर्ण मान द्वारा लुकअप तालिका को अनुक्रमित कर सकते हैं। हालाँकि, यदि प्रोग्रामिंग भाषा अहस्ताक्षरित पूर्णांक का समर्थन नहीं करती है तो आप क्या करते हैं? आपके पास किसी सरणी में नकारात्मक अनुक्रमणिका होगी। खैर, मुझे लगता है कि आप कुछ का उपयोग कर सकते हैं, charval + 128लेकिन यह सिर्फ बदसूरत है।

कई फ़ाइल प्रारूप, वास्तव में, अहस्ताक्षरित पूर्णांक का उपयोग करते हैं और यदि अनुप्रयोग प्रोग्रामिंग भाषा अहस्ताक्षरित पूर्णांक का समर्थन नहीं करती है, तो यह समस्या हो सकती है।

फिर टीसीपी अनुक्रम संख्या पर विचार करें। यदि आप कोई टीसीपी प्रोसेसिंग कोड लिखते हैं, तो आप निश्चित रूप से अहस्ताक्षरित पूर्णांक का उपयोग करना चाहेंगे।

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

मेरा तर्क है कि अहस्ताक्षरित पूर्णांक प्रकारों (मिश्रित संकेत अंकगणित, मिश्रित संकेत तुलना) का उपयोग करने से बचने का औचित्य उचित चेतावनी के साथ एक संकलक द्वारा दूर किया जा सकता है। इस तरह की चेतावनी आमतौर पर डिफ़ॉल्ट रूप से सक्षम नहीं होती है, लेकिन उदाहरण के लिए -Wextraया अलग से देखें -Wsign-compare(सी-बाय में ऑटो-सक्षम -Wextra, हालांकि मुझे नहीं लगता कि यह सी ++ में ऑटो-सक्षम है) और -Wsign-conversion।

फिर भी, यदि संदेह है, तो हस्ताक्षरित प्रकार का उपयोग करें। कई बार, यह एक विकल्प है जो अच्छी तरह से काम करता है। और उन संकलक चेतावनियों को सक्षम करें!

Answer 6

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

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

बहुत ही दुर्लभ स्थिति में जहां सूचकांक 2 ^ 31 से अधिक होता है, लेकिन 2 ^ 32 नहीं होता है, आप अहस्ताक्षरित पूर्णांक का उपयोग नहीं करते हैं, आप 64 बिट पूर्णांक का उपयोग करते हैं।

अंत में, एक अच्छा जाल: एक पाश में "के लिए" (i = 0; मैं <n; ++ i) एक पॉइंटर को बढ़ाकर [i] तक पहुंच, क्योंकि i = 2 ^ 32 - 1 के आसपास मैं लपेटता हूं। यहां तक ​​कि जब n कि बड़े कभी नहीं मिलता है। हस्ताक्षरित पूर्णांक का उपयोग करने से यह बचा जाता है।

Answer 7

अंत में, मुझे यहां एक बहुत अच्छा जवाब मिला: जे.वीगा और एम। मिसेयर ( http://shop.oreilly.com/product/9780596003944.do ) द्वारा "सुरक्षित प्रोग्रामिंग कुकबुक"।

हस्ताक्षरित पूर्णांक के साथ सुरक्षा मुद्दे:

1. यदि फ़ंक्शन को एक सकारात्मक पैरामीटर की आवश्यकता होती है, तो निचली श्रेणी की जांच करना भूलना आसान है।
2. नकारात्मक पूर्णांक आकार रूपांतरणों से एकरूप बिट पैटर्न।
3. एक नकारात्मक पूर्णांक के सही बदलाव ऑपरेशन द्वारा निर्मित अनइंस्टिट्यूट बिट पैटर्न।

हस्ताक्षरित <-> अहस्ताक्षरित रूपांतरणों के साथ समस्याएं हैं इसलिए मिश्रण का उपयोग करना उचित नहीं है।

Comments

यह एक अच्छा जवाब क्यों है? नुस्खा 3.5 क्या है? यह पूर्णांक अतिप्रवाह आदि के बारे में क्या कहता है?

— बाल्ड्रिक

मेरे व्यावहारिक अनुभव में यह मूल्यवान सलाह के साथ बहुत अच्छी किताब है, जो मैंने कोशिश की है और यह इस सिफारिश में बहुत दृढ़ है। 4 जी की तुलना में लंबे समय तक सरणियों पर पूर्णांक के खतरों के मुकाबले काफी कमजोर लगते हैं। अगर मुझे उस बड़े से बकाया से निपटना है, तो मेरे कार्यक्रम में प्रदर्शन दंड से बचने के लिए बहुत अच्छी ट्यूनिंग होगी।

— zzz777 12

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

— बाल्ड्रिक

FYI ने सिर्फ अहस्ताक्षरित पूर्णांक का उपयोग करने के एक और कारण के बारे में सीखा है: कोई आसानी से ओवरलो का पता लगा सकता है: youtube.com/…

— zzz777