शायद प्रदर्शन? मुझे लगता है कि गैर-निश्चित पूर्णांक का उपयोग करने से प्रोग्राम अधिक जटिल हो जाते हैं और किसी अन्य आर्किटेक्चर को पोर्ट करते समय असफल होने लगते हैं।क्या निश्चित आकार वाले (int64_t, int32_t) के बजाय गैर-निश्चित पूर्णांक (int, long) का उपयोग करने का कोई फायदा है?
std::intN_tonly if the implementation can directly support them प्रदान किए जाते हैं। तो पोर्टिंग कोड जो उनका उपयोग करता है असफल हो सकता है।
मैं सामान्य उपयोग के लिए std::intfastN_t पसंद करूंगा क्योंकि उनके पास कम प्रतिबंध हैं और int के रूप में तेज़ या तेज़ होना चाहिए।
साथ ही, अधिकांश सी ++ कोड हर जगह int का उपयोग करता है ताकि आप जब एक int को स्वीकार करने के लिए एक समारोह में एक std::int32_t गुजर पदोन्नति weirdness में आ सकते हैं, खासकर अगर sizeof(int) केवल 16 बिट्स है।
कई एपीआई गैर-निर्धारित प्रकार के मान स्वीकार या वापस करते हैं। उदाहरण के लिए, फ़ाइल डिस्क्रिप्टर int प्रकार हैं, फ़ाइल ऑफसेट या आकार off_t और strtol() प्रकार long लौटाते हैं। इस तरह के मूल्यों को निश्चित रूप से या निश्चित आकार के प्रकारों में परिवर्तित करने से कुछ मशीनों पर अतिप्रवाह होने की संभावना है।
गारंटी-चौड़ाई प्रकार (intN_t) उपयुक्त 'मानक' पूर्णांक प्रकारों के लिए केवल टाइपपीफ हैं। यदि किसी प्लेटफ़ॉर्म में उचित प्रकार नहीं है (उदाहरण के लिए, यह 36-बिट पूर्णांक का उपयोग करता है), तो यह गारंटीकृत-चौड़ाई टाइपिफ़ी प्रदान नहीं कर सकता है और नहीं। इसका मतलब है कि प्रदर्शन शायद ही कोई तर्क हो सकता है।
अधिकतम पोर्टेबिलिटी (इस संबंध में) के लिए सामान्य दिशानिर्देश डिफ़ॉल्ट रूप से 'मानक' पूर्णांक प्रकारों का उपयोग करना है और गारंटीकृत-चौड़ाई प्रकार केवल तभी होता है जब आपका एल्गोरिदम बिट्स की सटीक संख्या मांगता हो। 'मानक' पूर्णांक प्रकारों को प्रासंगिक मानकों द्वारा गारंटी के रूप में केवल चौड़ा माना जाना चाहिए (यदि आप केवल सी ++ मानक देखते हैं, तो यह होगा: 8-बिट्स char, 16-बिट int, 32-बिट long और , यदि आपका कंपाइलर इसका समर्थन करता है, 64-बिट long long)।
यदि आपके पास डेटा है जहां आपके प्रकार का आकार इसकी कार्यक्षमता के लिए महत्वपूर्ण है, तो आपको परिभाषित आकारों के प्रकारों का उपयोग करना चाहिए। हालांकि, उदाहरण के लिए कोड का एक टुकड़ा जो [आप जो उचित रूप से उम्मीद कर सकते हैं] int श्रेणी (उदाहरण 1 के लिए कहें ... 1000 लूप काउंटर), int_32t का उपयोग करने का कोई कारण नहीं है क्योंकि आप इसे अपना चर परिभाषित करना चाहते हैं । यह 16, 32, 64, 36, 18 या 49 बिट पूर्णांक के साथ ठीक काम करेगा, वही। तो कंपाइलर को सबसे अच्छा आकार चुनने दें।
ऐसी संभावना है कि संकलक निश्चित आकार पूर्णांक के लिए खराब कोड उत्पन्न करता है जो आर्किटेक्चर के लिए "सर्वश्रेष्ठ विकल्प" नहीं है।
जाहिर है, नेटवर्क या फ़ाइल में प्रस्तुत किए गए किसी भी डेटा को निश्चित आकार होना चाहिए। इसी तरह, यदि आपके पास इंटरफ़ेस हैं जो इंटरफ़ेस सीमा में बाइनरी संगतता की आवश्यकता है, तो परिभाषित आकार प्रकारों का उपयोग करना एक समस्या बनने के आकार से बचने के लिए बहुत उपयोगी है।
मुझे लगता है कि सटीक आकार मेरे कोड में बहुत ही कम मायने रखता है - उन मामलों में, निश्चित आकार के पूर्णांक का उपयोग करके केवल क्रूरता जोड़ता है और पोर्टेबिलिटी को कम करता है। आप क्या कर रहे हैं जिसके लिए आपको थोड़ा आकार जानने की आवश्यकता है? – delnan
मुझे लगता है कि यह उन मान्यताओं के लिए आता है जिन्हें आप बनाना चाहते हैं। क्या आप यह मानना चाहते हैं कि किसी विशेष मूल्य पर किसी भी विशिष्ट मूल्य पर हमेशा बिट्स की सटीक संख्या होगी? यदि ऐसा है, तो एक निश्चित आकार पूर्णांक सही विकल्प हो सकता है। यदि नहीं, तो आप केवल उस प्रकार का उपयोग करना चाहेंगे जो बिट्स की निश्चित न्यूनतम संख्या की गारंटी देता है। –