क्या एनएसआईएनटेगर वास्तव में हर जगह इस्तेमाल किया जाना चाहिए?

Question

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

यदि आपको उस मान को स्टोर करने की आवश्यकता है जो 32 बिट्स से अधिक नहीं है (उदाहरण के लिए एक लूप में जो केवल 25 बार लूप करता है), लंबे समय तक क्यों उपयोग किया जाना चाहिए, क्योंकि 32 (कम से कम) ऊपरी बिट्स जा रहे हैं खाली रहो

यदि कार्यक्रम 32-बिट पूर्णांक पर काम करता है, तो पूर्णांक के लिए 64-बिट्स का उपयोग करने से क्या लाभ होता है, जब यह अधिक मेमोरी का उपयोग करता है?

इसके अलावा ऐसी स्थितियां भी होंगी जहां 64-बिट पूर्णांक का उपयोग 32-बिट पूर्णांक का उपयोग करने के लिए एक अलग परिणाम देता है। तो यदि आप एनएसआईएनटेगर का उपयोग करते हैं तो कुछ आईफोन 5 एस पर काम कर सकता है लेकिन पुराने डिवाइस पर नहीं, जबकि अगर int या long स्पष्ट रूप से उपयोग किया जाता है तो परिणाम किसी भी डिवाइस पर समान होगा।

Answer 1

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

Answer 2

यदि आपको 32 बिट्स से अधिक नहीं होने वाला मान संग्रहीत करने की आवश्यकता है ... लंबे समय तक क्यों उपयोग किया जाना चाहिए?

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

यदि कार्यक्रम 32-बिट पूर्णांक पर काम करता है, तो पूर्णांक के लिए 64-बिट्स का उपयोग करने से क्या लाभ होता है, जब यह अधिक मेमोरी का उपयोग करता है?

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

इसके अलावा ऐसी स्थितियां भी होंगी जहां 64-बिट पूर्णांक का उपयोग 32-बिट पूर्णांक का उपयोग करने के लिए एक अलग परिणाम देता है? ...

हाँ, लेकिन जिस तरह से आप सोचेंगे। 32-बिट डेटा प्रकार और संचालन के साथ-साथ 64-बिट ऑपरेशंस (सॉफ़्टवेयर में सबसे अधिक अनुरूपित, या 32-बिट होस्ट्स में विशेष हार्डवेयर या ऑपोड द्वारा) उनके आकार के संदर्भ में "अपेक्षाकृत स्थिर" होते हैं। आप 64-बिट आर्किटेक्चर पर लगभग गारंटी नहीं दे सकते क्योंकि विभिन्न कंपाइलर 64-बिट डेटा प्रकारों के विभिन्न संस्करणों को लागू करते हैं (LP64, SILP64, and LLP64 देखें)। व्यावहारिक रूप से, इसका मतलब 64 बिट प्रकार को 32-बिट प्रकार में डालना है - एक इंटरेक्ट के लिए पॉइंटर कहें - सूचना हानि की ओर अग्रसर होने की गारंटी है, लेकिन 64 बिट्स होने की गारंटी वाले दो डेटा प्रकारों के बीच कास्टिंग - एक पॉइंटर और एक लंबा एलपी 64 पर - स्वीकार्य है। एआरएम आमतौर पर एलपी 64 का उपयोग करके संकलित किया जाता है (सभी चींटियां 32-बिट होती हैं, सभी लम्बाई 64-बिट होती है)।फिर, अधिकांश डेवलपर्स को स्विच से प्रभावित नहीं होना चाहिए, लेकिन जब आप मनमाने ढंग से बड़ी संख्याओं से निपटना शुरू करते हैं जिन्हें आप पूर्णांक में स्टोर करने का प्रयास करते हैं, तो सटीकता एक समस्या बन जाती है।

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

Answer 3

ऐप्पल पिछली संगतता की देखभाल करता है यदि आपका ऐप 32 या 64 बिट इंजन पर चल रहा है और __LP64__ मैक्रो का उपयोग करके दृश्यों के पीछे अपने चर को एक उचित डेटा प्रकार में परिवर्तित कर देगा।

#if __LP64__ 
    typedef long NSInteger; 
    typedef unsigned long NSUInteger; 
#else 
    typedef int NSInteger; 
    typedef unsigned int NSUInteger; 
#endif