जावा में विभिन्न आकार की संख्याओं के लिए आदिम क्यों है?

Question

जावा में वहाँ के लिए आदिम प्रकार के होते हैं byte, short, intऔर longऔर के लिए एक ही बात floatऔर double। किसी व्यक्ति को एक आदिम मूल्य के लिए कितने बाइट्स का उपयोग करना चाहिए, यह निर्धारित करना क्यों आवश्यक है? क्या आकार केवल डायनेमिक रूप से निर्धारित नहीं किया जा सकता है यह इस बात पर निर्भर करता है कि कितनी बड़ी संख्या में पारित किया गया था?

मेरे विचार से 2 कारण हो सकते हैं:

1. डेटा के आकार को गतिशील रूप से सेट करने का मतलब है कि इसे गतिशील रूप से भी बदलने में सक्षम होने की आवश्यकता होगी। यह संभावित रूप से प्रदर्शन समस्याओं का कारण बन सकता है?
2. शायद प्रोग्रामर नहीं चाहेगा कि कोई व्यक्ति एक निश्चित आकार की तुलना में बड़ी संख्या का उपयोग करने में सक्षम हो और यह उन्हें इसे सीमित करने देता है।

मुझे अभी भी लगता है कि एकल intऔर floatप्रकार का उपयोग करके सरलता से बहुत कुछ हासिल किया जा सकता था, क्या कोई विशिष्ट कारण था कि जावा ने इस मार्ग पर नहीं जाने का फैसला किया?

Comments

डाउनवोटर्स के लिए, मैं यह जोड़ना चाहूंगा कि यह प्रश्न एक प्रश्न से जुड़ा है जिसका संकलन करने वाले शोधकर्ता उत्तर देना चाहते हैं ।

— रवांग

इसलिए यदि आप एक संख्या में जोड़ते हैं तो आपको लगता है कि प्रकार को गतिशील रूप से बदलना चाहिए? क्या मैं भी चाहता हूं कि टाइप बदल जाए? यदि संख्या को अज्ञात अल्फा = a + b के रूप में प्रारंभ किया जाता है; क्या आपको लगता है कि संकलक पर थोड़ा मुश्किल होगा। यह जावा के लिए विशिष्ट क्यों है?

— पापाराज़ो

@Paparazzi मौजूदा प्रोग्रामिंग भाषाओं और निष्पादन वातावरण (कंपाइलर, दुभाषिए, आदि) हैं जो वास्तविक मूल्य कितना बड़ा है (जैसे अतिरिक्त ऑपरेशन का परिणाम) के आधार पर डायनेमिक-चौड़ाई पूर्णांक को संग्रहीत करेगा। परिणाम यह हैं कि: सीपीयू पर निष्पादित किया जाने वाला कोड अधिक जटिल हो जाता है; उस पूर्णांक का आकार गतिशील हो जाता है; मेमोरी से डायनेमिक चौड़ाई पूर्णांक पढ़ना एक से अधिक ट्रिप की आवश्यकता हो सकती है; संरचनाएं (ऑब्जेक्ट्स) और सरणियाँ जिनमें उनके क्षेत्रों / तत्वों के अंदर गतिशील चौड़ाई पूर्णांक होते हैं, उनके पास गतिशील आकार भी हो सकता है।

— रवांग

@tofro मुझे समझ में नहीं आता है। बस आपको जो भी फॉर्मेट पसंद है उसमें नंबर भेजें: दशमलव, बाइनरी, आदि। सीरियलाइजेशन पूरी तरह से ऑर्थोगोनल चिंता है।

— बाग़ का

@gardenhead यह ऑर्थोगोनल है, हाँ, लेकिन ... केवल उस मामले पर विचार करें जहाँ आप जावा में लिखे सर्वर और सी में लिखे क्लाइंट के बीच संवाद करना चाहते हैं। बेशक यह एक समर्पित बुनियादी ढांचे के साथ हल किया जा सकता है। जैसे कि Developers.google.com/protocol-buffers जैसी चीजें हैं । लेकिन यह नेटवर्क पर पूर्णांक संख्या को स्थानांतरित करने के छोटे अखरोट के लिए एक बड़ा स्लेजहैमर है। (मुझे पता है, यह यहाँ एक मजबूत तर्क नहीं है, लेकिन शायद विचार करने के लिए एक बिंदु - विवरण पर चर्चा करना टिप्पणियों के दायरे से परे है)।

— मार्को 13

Answer 1

भाषा के डिजाइन के कई पहलुओं की तरह, यह प्रदर्शन के खिलाफ लालित्य का व्यापार बंद हो जाता है (पूर्व भाषाओं से कुछ ऐतिहासिक प्रभाव का उल्लेख नहीं करना)।

वैकल्पिक

यह एक प्रोग्रामिंग भाषा बनाने के लिए निश्चित रूप से (और काफी सरल) है जिसमें एक ही प्रकार की प्राकृतिक संख्याएं हैं nat। अकादमिक अध्ययन के लिए उपयोग की जाने वाली लगभग सभी प्रोग्रामिंग भाषाओं (जैसे पीसीएफ, सिस्टम एफ) में यह एकल नंबर प्रकार है, जो कि अधिक सुंदर समाधान है, जैसा कि आपने सर्माइज़ किया है। लेकिन व्यवहार में भाषा डिजाइन केवल लालित्य के बारे में नहीं है; हमें प्रदर्शन पर भी विचार करना चाहिए (प्रदर्शन किस हद तक माना जाता है यह भाषा के अभिप्रेरित अनुप्रयोग पर निर्भर करता है)। प्रदर्शन में समय और स्थान की कमी दोनों शामिल हैं।

अंतरिक्ष की कमी

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

दक्षता

यहां तक ​​कि अगर हम अंतरिक्ष की उपेक्षा करते हैं, तो हम अभी भी सीपीयू द्वारा विवश हैं, जिसमें केवल निर्देश हैं जो एक निश्चित संख्या में बाइट्स पर काम करते हैं (64-बिट वास्तुकला पर 8 बाइट्स)। साधन एक भी 8-बाइट उपलब्ध कराने कि long, एक असीम प्राकृतिक संख्या प्रकार के होने की तुलना में काफी सरल भाषा के कार्यान्वयन होगा सीधे एक करने के लिए अंकगणितीय आपरेशनों मैप करने के लिए सक्षम होने से प्रकार एकल अंतर्निहित सीपीयू निर्देश। यदि आप प्रोग्रामर को मनमाने तरीके से बड़ी संख्या में उपयोग करने की अनुमति देते हैं, तो एक एकल अंकगणितीय ऑपरेशन को जटिल मशीन निर्देशों के अनुक्रम में मैप किया जाना चाहिए , जो प्रोग्राम को धीमा कर देगा। यह वह बिंदु (1) है जिसे आपने उठाया था।

फ्लोटिंग-पॉइंट प्रकार

अब तक की चर्चा में केवल संबंधित पूर्णांक हैं। फ्लोटिंग-पॉइंट प्रकार एक जटिल जानवर हैं, जिसमें अत्यंत सूक्ष्म शब्दार्थ और किनारे-मामले हैं। इस प्रकार, भले ही हम आसानी से बदल सकते int, long, short, और byteएक एकल के साथ natप्रकार, यह स्पष्ट नहीं है कि क्या चल बिन्दु संख्या के प्रकार भी है । वे वास्तविक संख्याएं नहीं हैं, जाहिर है, क्योंकि प्रोग्रामिंग भाषा में वास्तविक संख्याएं मौजूद नहीं हो सकती हैं। वे काफी तर्कसंगत संख्याएँ नहीं हैं, या तो (यदि यह वांछित है तो एक तर्कसंगत प्रकार बनाने के लिए आगे-आगे है)। मूल रूप से, IEEE ने थोड़े अनुमानित वास्तविक संख्याओं के लिए एक तरह से निर्णय लिया, और सभी भाषाएँ (और प्रोग्रामर) तब से उनके साथ अटकी हुई हैं।

आखिरकार:

शायद प्रोग्रामर नहीं चाहेगा कि कोई व्यक्ति एक निश्चित आकार की तुलना में बड़ी संख्या का उपयोग करने में सक्षम हो और यह उन्हें इसे सीमित करने देता है।

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

Comments

इस तथ्य की असली कुंजी कि हमारे पास फ्लोट्स हैं, हमारे पास उनके लिए हार्डवेयर समर्पित है

— jk।

एक प्रकार के संख्यात्मक सीमा को एन्कोडिंग भी पूरी तरह से निर्भर भाषाओं में होता है, और कुछ हद तक अन्य भाषाओं जैसे कि एनमोंस

— जेके।

एनमर्स पूर्णांक के समतुल्य नहीं हैं। एनम केवल राशि-प्रकार के उपयोग की एक विधि है। तथ्य यह है कि कुछ भाषाएँ पारदर्शी रूप से एनमोड को एनकोड करती हैं क्योंकि यह एक भाषा दोष है, एक शोषक विशेषता नहीं है।

— बाग़

मैं आद्या से परिचित नहीं हूं। क्या मैं पूर्णांक को किसी भी प्रकार तक सीमित कर सकता हूं, जैसे type my_type = int (7, 2343)?

— 18

हां। वाक्य रचना इस प्रकार होगी: my_type की सीमा 7..2343 है

— Devsman

Answer 2

कारण बहुत सरल है: दक्षता । कई तरीकों से।

1. मूल डेटा प्रकार: किसी भाषा के डेटा प्रकार, हार्डवेयर के अंतर्निहित डेटा प्रकारों से मेल खाते हैं, भाषा को जितना अधिक कुशल माना जाता है। (इस अर्थ में नहीं कि आपके कार्यक्रम आवश्यक रूप से कुशल होंगे, लेकिन इस अर्थ में कि आप हो सकते हैं, यदि आप वास्तव में जानते हैं कि आप क्या कर रहे हैं, तो कोड लिखें जो हार्डवेयर के रूप में कुशल हो सकता है। इसे चला सकते हैं।) जावा बाइट्स, शब्द, डबल पासवर्ड और सबसे लोकप्रिय हार्डवेयर के क्वाडवर्ड्स के अनुरूप है। यह जाने का सबसे कारगर तरीका है।

2. 32-बिट सिस्टम पर अनियंत्रित ओवरहेड: यदि 64-बिट लंबे आकार के लिए सब कुछ मैप करने का निर्णय लिया गया था, तो इससे 32-बिट आर्किटेक्चर पर भारी जुर्माना लगाया जा सकता था, जिसे 64 घंटे प्रदर्शन करने के लिए अधिक घड़ी चक्र की आवश्यकता होती है। 32-बिट ऑपरेशन की तुलना में बिट ऑपरेशन।

3. मेमोरी बेकारपन: वहाँ बहुत सारे हार्डवेयर है जो कि मेमोरी संरेखण के बारे में बहुत अधिक उपयुक्त नहीं है, (इंटेल x86 और x64 आर्किटेक्चर उस के उदाहरण हैं), इसलिए उस हार्डवेयर पर 100 बाइट्स की एक सरणी मेमोरी के केवल 100 बाइट्स पर कब्जा कर सकती है। हालांकि, यदि आपके पास अब बाइट नहीं है, और आपको इसके बजाय एक लंबे समय का उपयोग करना है, तो वही सरणी अधिक स्मृति के आदेश पर कब्जा कर लेगी। और बाइट सरणियाँ बहुत आम हैं।

4. संख्या के आकार की गणना: पूर्णांक के आकार को गतिशील रूप से निर्धारित करने की आपकी धारणा इस बात पर निर्भर करती है कि कितनी बड़ी संख्या में पारित किया गया है, यह बहुत ही सरल है; एक संख्या में "गुजर" का कोई एक बिंदु नहीं है; हर एक ऑपरेशन पर एक बड़े आकार के लिए कितनी बड़ी संख्या की आवश्यकता होती है, इसकी गणना के लिए बड़े आकार के परिणाम की आवश्यकता हो सकती है: हर बार जब आप एक नंबर बढ़ाते हैं, तो हर बार जब आप दो नंबर जोड़ते हैं, तो हर बार जब आप दो गुणा करते हैं नंबर, आदि।

5. विभिन्न आकारों की संख्याओं पर संचालन: इसके बाद, स्मृति में तैरने वाले संभावित विभिन्न आकारों की संख्या होने से सभी ऑपरेशन जटिल हो जाएंगे : यहां तक ​​कि केवल दो संख्याओं की तुलना करने के लिए, रनटाइम को पहले जांचना होगा कि क्या दोनों संख्याओं की तुलना एक जैसी है? आकार, और यदि नहीं, तो छोटे आकार का मिलान बड़े के आकार से करें।

6. ऐसे ऑपरेशन जिन्हें विशिष्ट ऑपरेंड आकार की आवश्यकता होती है: कुछ बिट-वार ऑपरेशन एक विशिष्ट आकार वाले पूर्णांक पर निर्भर करते हैं। पूर्व-निर्धारित विशिष्ट आकार नहीं होने से, इन परिचालनों का अनुकरण करना होगा।

7. बहुरूपता का उपरि: रनटाइम के समय संख्या का आकार बदलना अनिवार्य रूप से इसका मतलब है कि इसे बहुरूपता होना है। यह बदले में इसका मतलब है कि यह स्टैक पर आवंटित एक निश्चित आकार का आदिम नहीं हो सकता है, इसे एक ऑब्जेक्ट होना चाहिए, जो ढेर पर आवंटित किया गया है। यह बहुत अक्षम है। (ऊपर # 1 फिर से पढ़ें)

Answer 3

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

भाषा डिजाइन के नजरिए से

• यह निश्चित रूप से एक प्रोग्रामिंग भाषा और इसके निष्पादन वातावरण को डिजाइन और कार्यान्वित करने के लिए संभव है जो स्वचालित रूप से पूर्णांक संचालन के परिणामों को समायोजित करेगा जो मशीन की चौड़ाई में फिट नहीं होते हैं।
• यह भाषा डिजाइनर की पसंद है कि इस तरह की डायनामिक-चौड़ाई पूर्णांकों को इस भाषा के लिए डिफ़ॉल्ट पूर्णांक प्रकार बनाया जाए या नहीं।
• हालाँकि, भाषा डिजाइनर को निम्नलिखित कमियों पर विचार करना होगा:
  • सीपीयू को अधिक कोड निष्पादित करना होगा, जिसमें अधिक समय लगता है। हालांकि, सबसे लगातार मामले के लिए अनुकूलन करना संभव है जिसमें पूर्णांक एक मशीन शब्द के भीतर फिट बैठता है। टैग किए गए सूचक प्रतिनिधित्व देखें ।
  • उस पूर्णांक का आकार गतिशील हो जाता है।
  • मेमोरी से डायनेमिक चौड़ाई पूर्णांक पढ़ना एक से अधिक ट्रिप की आवश्यकता हो सकती है।
  • संरचनाएं (ऑब्जेक्ट्स) और सरणियाँ जिनमें उनके क्षेत्रों / तत्वों के अंदर डायनेमिक चौड़ाई पूर्णांक होते हैं, उनका कुल (कब्जा) आकार होगा जो कि गतिशील है।

ऐतिहासिक कारण

यह पहले से ही जावा के इतिहास के बारे में विकिपीडिया लेख में चर्चा की गई है, और मार्को 13 के उत्तर में भी संक्षेप में चर्चा की गई है ।

मैं यह बताना चाहूंगा:

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

दक्षता कारण

दक्षता कब मायने रखती है?

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

भंडारण की क्षमता (मेमोरी में, या डिस्क पर)

• कंप्यूटर मेमोरी कभी एक दुर्लभ संसाधन था। उन पुराने दिनों में, कंप्यूटर द्वारा संसाधित किए जा सकने वाले एप्लिकेशन डेटा का आकार कंप्यूटर मेमोरी की मात्रा तक सीमित था, हालांकि यह यकीनन चतुर प्रोग्रामिंग का उपयोग करके काम किया जा सकता था (जिसे लागू करने में अधिक लागत आएगी)।

निष्पादन की क्षमता (सीपीयू के भीतर, या सीपीयू और मेमोरी के बीच)

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

छोटे भाषाओं के लिए अमूर्तता प्रदान करने के लिए प्रोग्रामिंग भाषाओं की आवश्यकता, भले ही विशिष्ट संदर्भों तक सीमित हो

• ये जरूरतें सॉफ्टवेयर लाइब्रेरी के विकास में अक्सर पैदा होती हैं, जिसमें भाषा की अपनी मानक लाइब्रेरी भी शामिल है। नीचे ऐसे कई मामले हैं।

इंटरोऑपरेबिलिटी

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

स्ट्रिंग हैंडलिंग

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

फ़ाइल प्रारूप हैंडलिंग

• बहुत सारे फ़ाइल प्रारूप C- जैसी मानसिकता के साथ डिज़ाइन किए गए थे। जैसे, संकीर्ण चौड़ाई वाले खेतों का उपयोग प्रचलित था।

वांछनीयता, सॉफ्टवेयर गुणवत्ता और प्रोग्रामर की जिम्मेदारी

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

निम्नलिखित परिदृश्य पर विचार करें।

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

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

इसका अर्थ है ओपी का दृष्टिकोण,

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

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

Answer 4

यह सब हार्डवेयर से आता है।

अधिकांश हार्डवेयर पर एक बाइट मेमोरी की सबसे छोटी पता योग्य इकाई है।

आपके द्वारा बताए गए हर प्रकार को कुछ कई बाइट्स से बनाया गया है।

एक बाइट 8 बिट है। इसके साथ आप 8 बूलियन्स को व्यक्त कर सकते हैं लेकिन आप एक बार में सिर्फ एक को नहीं देख सकते। आप 1 को संबोधित करते हैं, आप सभी 8 को संबोधित कर रहे हैं।

और यह इतना सरल हुआ करता था लेकिन तब हम 8 बिट बस से 16, 32 और अब 64 बिट बस से चले गए।

इसका मतलब यह है कि जब हम अभी भी बाइट के स्तर पर पता कर सकते हैं, तो हम अपने पड़ोसी बाइट्स को प्राप्त किए बिना मेमोरी से एक भी बाइट प्राप्त नहीं कर सकते हैं।

इस हार्डवेयर का सामना करते हुए भाषा डिजाइनरों ने हमें उन प्रकारों को चुनने की अनुमति दी, जो हमें हार्डवेयर फिट करने वाले प्रकारों को चुनने की अनुमति देते हैं।

आप दावा कर सकते हैं कि इस तरह के विवरण को विशेष रूप से एक भाषा में दूर किया जा सकता है और इसका उद्देश्य किसी भी हार्डवेयर पर चलना है। इससे प्रदर्शन की चिंताएं छिपी होंगी लेकिन आप सही हो सकते हैं। यह सिर्फ इस तरह से नहीं हुआ।

जावा वास्तव में ऐसा करने की कोशिश करता है। बाइट्स को स्वचालित रूप से Ints में बढ़ावा दिया जाता है। एक तथ्य जो आपको पागल कर देगा, जब आप पहली बार इसमें कोई गंभीर बिट शिफ्टिंग कार्य करने की कोशिश करेंगे।

तो क्यों यह अच्छी तरह से काम नहीं किया?

जावा के बड़े सेलिंग पॉइंट उस दिन के तरीके से जब आप एक ज्ञात अच्छे सी एल्गोरिथ्म के साथ बैठ सकते हैं, इसे जावा में टाइप करें, और मामूली ट्विक्स के साथ यह काम करेगा। और C हार्डवेयर के बहुत करीब है।

अभिन्न प्रकार से बाहर जा रहा है और अमूर्त आकार रखते हुए बस एक साथ काम नहीं किया।

तो वे हो सकते थे। उन्होंने अभी नहीं किया।

शायद प्रोग्रामर नहीं चाहेगा कि कोई व्यक्ति एक निश्चित आकार की तुलना में बड़ी संख्या का उपयोग करने में सक्षम हो और यह उन्हें इसे सीमित करने देता है।

यह मान्य सोच है। ऐसा करने के लिए तरीके हैं। क्लैंप समारोह एक के लिए। एक भाषा इतनी दूर तक जा सकती है कि उनके प्रकारों में मनमानी सीमाएं बांध सकें। और जब उन सीमाओं को संकलन समय पर जाना जाता है जो उन संख्याओं को कैसे संग्रहीत किया जाता है में अनुकूलन की अनुमति देगा।

जावा सिर्फ वह भाषा नहीं है।

Comments

" एक भाषा इतनी दूर तक जा सकती है कि उनके प्रकारों में मनमानी सीमाएं बांध सकें " और वास्तव में पास्कल के पास अजीब प्रकार के साथ इसका एक रूप है।

— पीटर टेलर

Answer 5

संभवतः, जावा में इन प्रकारों के मौजूद होने का एक महत्वपूर्ण कारण सरल और कष्टप्रद गैर-तकनीकी है:

C और C ++ में भी ये प्रकार थे!

हालांकि यह प्रमाण देना कठिन है कि यह कारण है, कम से कम कुछ मजबूत साक्ष्य हैं: ओक भाषा विनिर्देश (संस्करण 0.2) में निम्नलिखित मार्ग शामिल हैं:

3.1 पूर्णांक प्रकार

ओक भाषा में पूर्णांक सी और सी ++ में दो अपवादों के समान हैं: सभी पूर्णांक प्रकार मशीन स्वतंत्र हैं, और कुछ पारंपरिक परिभाषाओं को बदल दिया गया है क्योंकि दुनिया में परिवर्तन सी को पेश किया गया था। चार पूर्णांक प्रकारों में 8, 16, 32 और 64 बिट्स की चौड़ाई होती है, और जब तक unsignedसंशोधक द्वारा उपसर्ग नहीं किया जाता है तब तक हस्ताक्षर किए जाते हैं ।

तो सवाल नीचे उबाल सकता है:

C में छोटे, int, और लंबे आविष्कार क्यों किए गए?

मुझे यकीन नहीं है कि पत्र प्रश्न का उत्तर यहां पूछे गए प्रश्न के संदर्भ में संतोषजनक है या नहीं। लेकिन यहां अन्य उत्तरों के साथ संयोजन में, यह स्पष्ट हो सकता है कि इन प्रकारों के लिए फायदेमंद हो सकता है (चाहे जावा में उनका अस्तित्व केवल C / C ++ से एक विरासत है)।

सबसे महत्वपूर्ण कारण जो मैं सोच सकता हूं

• एक बाइट सबसे छोटी पता योग्य मेमोरी यूनिट है (जैसा कि कैंडिडऑरेन्ज पहले ही उल्लेख किया गया है)। A byteडेटा का प्राथमिक निर्माण खंड है, जिसे किसी फ़ाइल या नेटवर्क पर पढ़ा जा सकता है। इसका कुछ स्पष्ट प्रतिनिधित्व मौजूद होना चाहिए (और यह ज्यादातर भाषाओं में मौजूद है, तब भी जब यह कभी-कभी भेस में आता है)।

• यह सच है कि, व्यवहार में, यह एक प्रकार का उपयोग करके सभी क्षेत्रों और स्थानीय चर का प्रतिनिधित्व करने के लिए समझ में आता है, और इस प्रकार को कॉल करता है int। स्टैकओवरफ्लो पर उस से संबंधित एक प्रश्न है: जावा एपीआई शॉर्ट या बाइट के बजाय इंट का उपयोग क्यों करता है? । जैसा कि मैंने अपने उत्तर में उल्लेख किया है, छोटे प्रकारों ( byteऔर short) के लिए एक औचित्य यह है कि आप इन प्रकारों के सरणियों को बना सकते हैं : जावा में उन सरणियों का प्रतिनिधित्व है जो अभी भी "हार्डवेयर के करीब" हैं। अन्य भाषाओं के विपरीत (और वस्तुओं के सरणियों के विपरीत, एक Integer[n]सरणी की तरह ), एक int[n]सरणी संदर्भों का एक संग्रह नहीं है जहां मान पूरे ढेर में बिखरे हुए हैं। इसके बजाय, यह होगाव्यवहार में n*4बाइट्स का लगातार ब्लॉक होना चाहिए - एक ज्ञात आकार और डेटा लेआउट के साथ मेमोरी का एक हिस्सा। जब आपके पास मनमाने ढंग से पूर्णांक मूल्य की वस्तुओं के संग्रह में 1000 बाइट्स रखने का विकल्प होता है, या byte[1000](जो 1000 बाइट्स लेता है), तो उत्तरार्द्ध वास्तव में कुछ मेमोरी को बचा सकता है। (इसके कुछ अन्य लाभ अधिक सूक्ष्म हो सकते हैं, और केवल तभी स्पष्ट हो सकते हैं जब मूल पुस्तकालयों के साथ जावा को प्रतिस्थापित किया जाता है)

---

उन बिंदुओं के बारे में जो आपने विशेष रूप से पूछे हैं:

क्या आकार केवल डायनेमिक रूप से निर्धारित नहीं किया जा सकता है यह इस बात पर निर्भर करता है कि कितनी बड़ी संख्या में पारित किया गया था?

डेटा के आकार को गतिशील रूप से सेट करने का मतलब है कि इसे गतिशील रूप से भी बदलने में सक्षम होने की आवश्यकता होगी। यह संभावित रूप से प्रदर्शन समस्याओं का कारण बन सकता है?

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

---

साइड नोट्स:

• आप सोच भी सकते हैं कि unsignedओक कल्पना में उल्लिखित संशोधक के बारे में क्या था। वास्तव में, इसमें एक टिप्पणी भी शामिल है: " unsignedअभी तक लागू नहीं किया गया है; यह कभी नहीं हो सकता है।" । और वे सही थे।

• यह सोचने के अलावा कि C / C ++ में ये अलग-अलग पूर्णांक प्रकार क्यों थे, आप आश्चर्यचकित हो सकते हैं कि उन्होंने क्यों उन्हें इतनी बुरी तरह से गड़बड़ कर दिया कि आप कभी नहीं जानते कि कितने बिट्स हैं int। इसके लिए औचित्य आमतौर पर प्रदर्शन से संबंधित हैं, और कहीं और देखा जा सकता है।

Answer 6

यह निश्चित रूप से दिखाता है कि आपने अभी तक प्रदर्शन और आर्किटेक्चर के बारे में नहीं पढ़ाया है।

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

डेटा आकार के महत्व को अनदेखा करना हमेशा प्रदर्शन को प्रभावित करता है, आपको आवश्यक के रूप में कई संसाधनों का उपयोग करना चाहिए, लेकिन हमेशा नहीं!

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

Answer 7

कुछ अच्छे कारण हैं

(1) जबकि एक बाइट चर छंद का भंडारण एक लंबा है, एक सरणी में लाखों का भंडारण बहुत महत्वपूर्ण है।

(2) विशेष पूर्णांक आकार के आधार पर "हार्डवेयर देशी" अंकगणित बहुत अधिक कुशल हो सकता है, और कुछ प्लेटफार्मों पर कुछ एल्गोरिदम के लिए, जो महत्वपूर्ण हो सकता है।