सी # में, System.Int32 के लिए "int" उपनाम क्यों है?

Question

सी # Int8, Int16, Int32 और Int64 का समर्थन करता है के बाद से, क्यों भाषा के डिजाइनर Int32 के लिए एक उपनाम के रूप int को परिभाषित करने के बजाय यह क्या देशी वास्तुकला एक word मानता है के आधार पर भिन्न करने के लिए अनुमति की चुना?

मुझे int के लिए अलग-अलग तरीके से व्यवहार करने के लिए कोई विशिष्ट आवश्यकता नहीं है, मैं केवल शुद्ध विश्वकोशिक रुचि से पूछ रहा हूं।

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

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

_{नोट 1: मैं वास्तव में किया था सभी उत्तर और SO: Is it safe to assume an int will always be 32 bits in C#? के सभी टिप्पणियां पढ़ें लेकिन क्यों कि मैं इस सवाल में पूछ रहा हूँ के बारे में कोई संकेत नहीं मिला।}

_{नोट 2: पर ऐसा ही है (inconclusively) इस सवाल की व्यवहार्यता यहाँ पर चर्चा की: Meta: Can I ask a “why did they do it this way” type of question?}

Answer 1

मुझे विश्वास है कि उनके मुख्य कारण को लक्षित CLR कार्यक्रमों के पोर्टेबिलिटी था। यदि वे प्लेटफार्म-निर्भर होने के लिए int के रूप में मूल प्रकार की अनुमति देने के लिए थे, तो सीएलआर के लिए पोर्टेबल प्रोग्राम बनाना बहुत कठिन हो जाएगा। typedef के प्रसारित प्लेटफार्म-तटस्थ सी/सी ++ कोड में अंतर्निहित int के उपयोग को कवर करने के लिए एक अप्रत्यक्ष संकेत है कि क्यों सीएलआर के डिजाइनरों ने अंतर्निहित प्रकार प्लेटफ़ॉर्म-स्वतंत्र बनाने का निर्णय लिया। इस तरह की विसंगतियां वीएम के आधार पर निष्पादन प्रणाली के लक्ष्य "कहीं भी लिखें, कहीं भी चलें" के लिए एक बड़ा अवरोधक हैं।

संपादित प्रायः, एक int परोक्ष सा आपरेशन के माध्यम से अपने कोड में नाटकों, बल्कि arithmetics के माध्यम से का आकार (सभी के बाद, संभवतः i++ साथ गलत हो सकता है क्या, है ना?) लेकिन त्रुटियाँ हैं आमतौर पर अधिक सूक्ष्म। नीचे दिए गए उदाहरण पर विचार करें:

const int MaxItem = 20; 
var item = new MyItem[MaxItem]; 
for (int mask = 1 ; mask != (1<<MaxItem) ; mask++) { 
    var combination = new HashSet<MyItem>(); 
    for (int i = 0 ; i != MaxItem ; i++) { 
     if ((mask & (1<<i)) != 0) { 
      combination.Add(item[i]); 
     } 
    } 
    ProcessCombination(combination); 
} 

यह कोड 20 आइटमों के सभी संयोजनों की गणना और प्रक्रिया करता है। जैसा कि आप बता सकते हैं, कोड 16-बिट int के साथ सिस्टम पर बुरी तरह विफल रहता है, लेकिन 32 या 64 बिट्स की स्याही के साथ ठीक काम करता है।

असुरक्षित कोड सिरदर्द का एक और स्रोत प्रदान करेगा: जब int कुछ आकार (कहें, 32) कोड पर तय किया गया है जो कि बाइट्स की संख्या 4 गुना आवंटित करता है क्योंकि इसे मार्शल की आवश्यकता होती है, यह sizeof(int) के स्थान पर 4 का उपयोग करने के लिए तकनीकी रूप से गलत है। इसके अलावा, यह तकनीकी रूप से गलत कोड पोर्टेबल रहेगा!

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

Answer 2

कई प्रोग्रामर के पास उनके द्वारा उपयोग किए जाने वाले प्लेटफ़ॉर्म के लिए कोड लिखने की प्रवृत्ति होती है। इसमें एक प्रकार के आकार के बारे में धारणाएं शामिल हैं। ऐसे कई सी प्रोग्राम हैं जो असफल हो जाएंगे यदि int का आकार 16 या 64 बिट में बदला जाएगा क्योंकि उन्हें धारणा के तहत लिखा गया था कि एक int 32 बिट है। सी # के लिए विकल्प उस समस्या को बस परिभाषित करके उस समस्या से बचाता है। यदि आप उसी समस्या में वापस प्लेटफार्म के आधार पर int के रूप में int को परिभाषित करते हैं। यद्यपि आप तर्क दे सकते हैं कि प्रोग्रामर गलतियों को गलत धारणा बनाने में गलती करते हैं, यह भाषा को थोड़ा और मजबूत बनाता है (आईएमओ)। और डेस्कटॉप प्लेटफ़ॉर्म के लिए 32 बिट int शायद सबसे आम अवसर है। इसके अलावा यह मूल सी कोड को सी # को थोड़ा आसान बनाता है।

संपादित करें: मुझे लगता है कि आप कोड लिखते हैं जो आपके विचार से अधिक प्रकार के साइज़र के बारे में अनुमान (अंतर्निहित) धारणा करता है। मूल रूप से कुछ भी जिसमें सीरियलाइजेशन शामिल है (जैसे .NET रिमोटिंग, डब्ल्यूसीएफ, डिस्क पर डेटा को क्रमबद्ध करना आदि) आपको परेशानी में डाल देगा यदि आप int के लिए वैरिएबल आकारों को अनुमति देते हैं जब तक प्रोग्रामर विशिष्ट आकार के प्रकार int32 का उपयोग करके इसका ख्याल रखता है। और फिर आप "अंत में int32 का उपयोग हमेशा वैसे ही करेंगे" और आप कुछ हासिल नहीं किया है।