2011-12-14 10 views
78

तो typedef का कारण: एड आदिम डेटा प्रकार निम्न-स्तरीय प्रतिनिधित्व को सारणीबद्ध करना है और long long प्रकार के बजाय uint64_t टाइप करना आसान है, जो 8 बाइट्स है)।uint_fast32_t क्या है और इसे नियमित int और uint32_t के बजाय क्यों उपयोग किया जाना चाहिए?

हालांकि, वहाँ uint_fast32_t जो एक ही typedefuint32_t के रूप में किया गया है। "तेज़" संस्करण का उपयोग प्रोग्राम को तेज़ी से बना देगा?

+0

लंबे समय तक 8 बाइट्स नहीं हो सकता है, 1 बाइट (यदि CHAR_BIT कम से कम 64 है) या 3738383 बाइट्स के साथ लंबा लंबा होना संभव है। uint64_t भी 1,2,4 या 8 बाइट हो सकता है, CHAR_BIT उस के लिए 64, 3, 16 या 8 होना चाहिए। – 12431234123412341234123

उत्तर

98
  • int कुछ प्लेटफ़ॉर्म पर 16 बिट्स जितना छोटा हो सकता है। यह आपके आवेदन के लिए पर्याप्त नहीं हो सकता है।
  • uint32_t मौजूद होने की गारंटी नहीं है। यह एक वैकल्पिक typedef है कि कार्यान्वयन को iff प्रदान करना होगा यदि उसके पास 32-बिट्स का एक हस्ताक्षरित पूर्णांक प्रकार है। उदाहरण के लिए कुछ में 9-बिट बाइट हैं, इसलिए उनके पास uint32_t नहीं है।
  • uint_fast32_t आपके इरादे को स्पष्ट रूप से बताता है: यह का एक प्रकार है 32 बिट्स जो प्रदर्शन बिंदु-दृश्य से सबसे अच्छा है। uint_fast32_t वास्तव में 64 बिट लंबा हो सकता है। यह कार्यान्वयन पर निर्भर है।

... वहाँ uint_fast32_t जो uint32_t रूप में एक ही typedef है ...

क्या आप देख रहे हैं मानक नहीं है। यह एक विशेष कार्यान्वयन (ब्लैकबेरी) है। तो आप वहां से घटा नहीं सकते हैं कि uint_fast32_t हमेशा uint32_t जैसा ही है।

यह भी देखें:

+20

अच्छा जवाब। पूर्णता के लिए, कोई भी 'uint_least32_t' में अंतर को इंगित कर सकता है, जो 'uint_fast32_t' जैसा ही है, सिवाय इसके कि यह गति के बजाय छोटे स्टोर का पक्ष लेता है। – Damon

+0

सबसे तेज़ पूर्णांक जो कम से कम 32-बिट चौड़ाई में 32-बिट से बड़ा क्यों होगा? मैंने हमेशा सोचा कि अगर कम बिट्स हैं, तो कम बिट्स सीपीयू पर काम करना होगा, इस प्रकार तेज़ी से। मुझे यहां क्या समझ नहीं आ रहा है? –

+6

@ShaneHsu: कहते हैं कि एक 64-बिट सीपीयू 64-बिट बिट गर्मी है, जो एक चक्र में 64-बिट संख्या का योग होगा। इससे कोई फर्क नहीं पड़ता कि आप 32-बिट संख्याओं पर काम करना चाहते हैं, यह एक चक्र से तेज़ नहीं होगा। अब, हालांकि यह x86/amd64 पर नहीं है, 32-बिट पूर्णांक भी एड्रेसेबल नहीं हो सकते हैं। ऐसे मामले में उन पर काम करने के लिए 64-बिट गठबंधन इकाइयों से 32-बिट्स निकालने के लिए अतिरिक्त सेप्स की आवश्यकता होती है। लिंक किए गए प्रश्न भी देखें। सी ++ मानक लिखा गया है ताकि यह उस मशीन पर काम कर सके जिसमें 37-बिट शब्द हैं ... तो 32-बिट प्रकार बिल्कुल नहीं। – ybungalobill

2

जब आप #include inttypes.h अपने कार्यक्रम में, आप पूर्णांकों का प्रतिनिधित्व करने के लिए अलग अलग तरीकों का एक समूह के लिए पहुँच जाते हैं।

uint_fast * _t प्रकार बस दिए गए बिट्स का प्रतिनिधित्व करने के लिए सबसे तेज़ प्रकार को परिभाषित करता है।

इस बारे में सोचें: आप short प्रकार के एक चर को परिभाषित करते हैं और प्रोग्राम में कई बार इसका उपयोग करते हैं, जो पूरी तरह से मान्य है। हालांकि, जिस सिस्टम पर आप काम कर रहे हैं वह int के मानों के साथ अधिक तेज़ी से काम कर सकता है। एक चर को uint_fast*t के रूप में परिभाषित करके, कंप्यूटर बस सबसे कुशल प्रतिनिधित्व चुनता है जिसके साथ यह काम कर सकता है।

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

+8

क्यों inttypes.h और stdint.h नहीं? ऐसा लगता है कि प्रकृति।एच में केवल हल्के रूप से उपयोगी फ्लाफ, साथ ही stdint.h शामिल हैं? – Lundin

+0

@ रेफरी के लिए लंदन: http://stackoverflow.com/a/9162072/2757035 –

+0

@underscore_d मुझे अंतर पता है। लेकिन पेशेवर कार्यक्रमों में stdio.h का उपयोग कौन करता है, आवेदन के क्षेत्र में कोई फर्क नहीं पड़ता? – Lundin

27

अंतर उनके सटीक और उपलब्धता में निहित है।

doc यहाँ का कहना है:

:

की चौड़ाई के साथ अहस्ताक्षरित पूर्णांक प्रकार बिल्कुल 8, 16, 32 और 64 बिट क्रमशः (प्रदान की कार्यान्वयन सीधे प्रकार का समर्थन करता है केवल यदि)

uint8_t 
uint16_t 
uint32_t 
uint64_t 

और

सबसे तेजी से अहस्ताक्षरित क्रमशः कम से कम 8, 16, 32 और 64 बिट की चौड़ाई

uint_fast8_t 
uint_fast16_t 
uint_fast32_t 
uint_fast64_t  

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

दूसरी ओर, uint_fast32_t एक प्रकार है जो कम से कम 32 बिट है, यह भी है जिसका अर्थ है, अगर एक कार्यान्वयन typedef सकता है uint32_t रूप uint_fast32_tअगर यह uint32_t प्रदान करता है। यदि यह uint32_t प्रदान नहीं करता है, तो uint_fast32_t किसी भी प्रकार का टाइपिफ़ हो सकता है जिसमें कम से कम 32 बिट्स हो सकते हैं।

+0

लेकिन कारण क्या है जो uint32fastt के लिए uint_fast32_t तेज बनाता है? यह तेज़ क्यों है? – Destructor

+2

@PravasiMeet: सभी integers एक ही तरीके से उपयोग नहीं किया। कुछ दूसरों की तुलना में आसान है। आसान मतलब कम गणना, अधिक प्रत्यक्ष, जिसके परिणामस्वरूप तेजी से पहुंच होती है। अब 'uint32_t' सभी प्रणालियों पर बिल्कुल 32-बिट है (यदि यह मौजूद है), जो कि 64-बिट के मुकाबले तेज नहीं हो सकता है। दूसरी तरफ 'uint_fast32_t' ** कम से कम ** 32 बिट, 64-बिट भी हो सकता है। – Nawaz

+6

@ डिस्ट्रक्टर: कुछ प्रोसेसर पर, यदि कोई चर एक रजिस्टर में संग्रहीत हो जाता है जो लंबे समय तक है, तो कंपाइलर को अतिरिक्त बिट्स को लॉप करने के लिए अतिरिक्त कोड जोड़ना पड़ सकता है। उदाहरण के लिए, यदि 'uint16_t x;' एआरएम 7-टीडीएमआई पर 32-बिट रजिस्टर में संग्रहीत हो जाता है, तो कोड 'x ++;' को 'x = ((x + 1) <<16)>> 16) के रूप में मूल्यांकन करने की आवश्यकता हो सकती है;' ' । उस प्लेटफॉर्म के लिए कंपाइलर्स पर, 'uint_fast16_t' को इससे बचने के लिए' uint32_t' के पर्याय के रूप में परिभाषित किया जाएगा। – supercat

0

ध्यान दें कि तेज़ संस्करण 32 बिट्स से बड़ा हो सकता है। जबकि फास्ट इंट एक रजिस्टर में अच्छी तरह से फिट होगा और गठबंधन होगा और जैसा: लेकिन, यह और अधिक स्मृति का उपयोग करेगा। यदि आपके पास इनमें से बड़े सरणी हैं तो आपका प्रोग्राम अधिक मेमोरी कैश हिट और बैंडविड्थ के कारण धीमा हो जाएगा।

मुझे नहीं लगता कि आधुनिक सीपीयूएस fast_int32 से लाभान्वित होगा, क्योंकि आम तौर पर लोड निर्देश के दौरान 32 से 64 बिट का विस्तार हो सकता है और यह विचार है कि एक 'देशी' पूर्णांक प्रारूप जो पुराना है, पुराना है ।

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

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