C ++: क्यों बूल 8 बिट लंबा है?


132

C ++ में, मैं सोच रहा हूं कि बूल टाइप 8 बिट लंबा (मेरे सिस्टम पर) क्यों है, जहां बूलियन मान रखने के लिए केवल एक बिट पर्याप्त है?

मुझे विश्वास था कि यह प्रदर्शन कारणों से था, लेकिन फिर 32 बिट्स या 64 बिट्स मशीन पर, जहां रजिस्टर 32 या 64 बिट्स चौड़े होते हैं, प्रदर्शन लाभ क्या है?

या यह सिर्फ इन 'ऐतिहासिक' कारणों में से एक है?


9
मेरे सिस्टम पर एक बूल 8 बिट्स नहीं है। यह 4 बाइट्स है, एक इंट के समान है।
ब्रायन नील

21
पिछली बार किसी ने सोचा था कि आप क्या सोच रहे हैं, हमने std :: वेक्टर <bool> के साथ समाप्त किया, सबसे नफरत वाला "फीचर" कभी =)
विक्टर सेहर

1
मुझे लगता है कि तुम मुझे गलत समझते हो। मैं एक प्रणाली के लिए पूछ रहा था, जहां sizeof(bool)4 होगा। मैं कसम खा सकता हूं कि एमएससीएक्स में 32-बिट बूल थे, लेकिन मैंने बस कोशिश की और यह नहीं करता है।
अवकर

7
निष्पक्ष होने के लिए, समस्या vector<bool>यह नहीं है कि यह चतुर होने और बिट्स को पैक करने की कोशिश करता है, लेकिन यह ऐसा करने की कोशिश करता है और एसटीएल कंटेनर के रूप में खुद को छिपाने का प्रयास करता है । एक सादा बिटसेट तब तक ठीक होता जब तक वह एसटीएल कंटेनर होने का दिखावा नहीं करता।
जालफ

2
@avakar - आप boolWindows BOOLप्रकार के साथ C ++ डेटा प्रकार को भ्रमित कर सकते हैं जिसे टाइप किया जाता है long। तो sizeof(bool) != sizeof(BOOL), जो मुझे यकीन है कि बहुत भ्रम का कारण बनता है (और शायद उचित संख्या में बग)। विशेष रूप से चूंकि विंडोज में भी हैं booleanऔर BOOLEANटाइपराइफ हैं, जो इसके लिए उपनाम हैं unsigned char। यह भी ध्यान दें कि जबकि यह bool1 बाइट के लिए सामान्य है , सी ++ मानक में एक नोट है जो विशेष रूप से इंगित करता है कि sizeof(bool)बड़ा हो सकता है।
माइकल बूर

जवाबों:


219

क्योंकि हर C ++ डेटा टाइप एड्रेस करने योग्य होना चाहिए।

आप एक सिंगल बिट को पॉइंटर कैसे बनाएंगे? आप नहीं कर सकते। लेकिन आप एक बाइट को पॉइंटर बना सकते हैं। इसलिए C ++ में एक बूलियन आमतौर पर बाइट के आकार का होता है। (यह बड़े होने के साथ-साथ लागू हो सकता है। मुख्य बात यह है कि यह पता योग्य होना चाहिए, इसलिए कोई C ++ डेटाटाइप बाइट से छोटा नहीं हो सकता)


7
"बाइट" को संबोधित करना एक वास्तुशिल्प विकल्प (hw स्तर) है: एक बहुत अच्छी तरह से एक अलग "पते की इकाई" के साथ एक प्रणाली को डिजाइन कर सकता है। सामान्य प्रोसेसर के लिए, "बाइट" को संबोधित करना किसी भी तरह से बाहरी मेमोरी से एक "बाइट" की तुलना में अधिक होता है: यह दक्षता कारणों के कारण है।
jldupont

8
हां, यह एक हार्डवेयर विकल्प है, और यदि हार्डवेयर इसके लिए अनुमति देता है, तो एक बूल का आकार बदल सकता है। लेकिन ओपी ने पूछा कि एक बूल 8 बिट चौड़ा क्यों है, और सिस्टम पर जहां मामला है, यह आमतौर पर है क्योंकि सीपीयू केवल 8-बिट बाइट्स को संबोधित करने में सक्षम है।
jalf

2
@jldupont: कुछ सिस्टम हैं जहां सूचक पते बाइट्स की तुलना में महीन होते हैं (मैंने पहले पुराने टीआई TMS34010 / 20 पर प्रोग्राम किया है, जो बिट-वार पॉइंटर्स का उपयोग करता है), लेकिन वे बेहद दुर्लभ हैं।
माइकल कोहेन

1
पक्का नहीं आपका क्या मतलब है। प्रत्येक वस्तु को पता योग्य होना चाहिए, अर्थात किसी वस्तु का पता पुनः प्राप्त करना संभव होना चाहिए। ऑब्जेक्ट को अपना पता संग्रहीत करने की आवश्यकता नहीं है। एक वर्ण आमतौर पर 8 बिट्स चौड़ा होता है, जो किसी भी 256 वर्णों को संग्रहीत करने के लिए पर्याप्त होता है, लेकिन प्रत्येक वर्ण में एक पता निर्धारित होता है कि स्मृति में यह कहाँ स्थित है। यही कारण है कि आप एक चार्ट के लिए एक पॉइंटर बना सकते हैं।
jalf

88
अगर मैं एक घिनौनी सादृश्य में योगदान दे सकता हूं: मेरे भवन में आठ मंजिल हैं, लेकिन डाकघर स्वीकार नहीं करता है कि वे अलग-अलग पते हैं। इसलिए अगर मुझे खुद से सभी का पता चाहिए, तो मुझे पूरी इमारत किराए पर देनी होगी, भले ही मैं वास्तव में एक मंजिल पर बैठूं। मैं अन्य सात मंजिलों को "एक पते को संग्रहीत करने के लिए" का उपयोग नहीं कर रहा हूं, मैं सिर्फ पोस्ट ऑफिस के नियम के कारण उन्हें बर्बाद करने के लिए मजबूर हूं जो पते इमारतों का उल्लेख करते हैं, न कि फर्श का। C ++ ऑब्जेक्ट्स का पता स्वयं के पास होना चाहिए - डिलीवरी के बाद मेल को सॉर्ट करने के लिए कोई पोस्ट रूम नहीं ;-)
स्टीव जेसप

39

मेमोरी बाइट एड्रेसेबल है। मेमोरी से पढ़ी गई बाइट को शिफ्ट या मास्क किए बिना आप एक बिट को संबोधित नहीं कर सकते। मुझे लगता है कि यह एक बहुत बड़ा कारण है।


1
हर बार नहीं। 8051 एमसीयू, उदाहरण के लिए, बिट पता स्थानों में से 16 बाइट्स है
समुद्रतटीय

20

एक booleanप्रकार आम तौर पर लक्ष्य मशीन (जैसे आमतौर पर 8 बिट्स) की पता योग्य मेमोरी की सबसे छोटी इकाई का अनुसरण करता है

मेमोरी तक पहुंच हमेशा "चंक्स" में होती है (कई शब्दों में, यह हार्डवेयर स्तर पर दक्षता के लिए है , बस लेनदेन): अधिकांश सीपीयू सिस्टम में बूलियन बिट को "अकेले" संबोधित नहीं किया जा सकता है। बेशक, एक बार डेटा एक रजिस्टर में निहित होने के बाद , बिट्स में स्वतंत्र रूप से हेरफेर करने के लिए अक्सर विशेष निर्देश होते हैं।

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

अपडेट किया गया : एक उत्कृष्ट चर्चा के लिए धन्यवाद, यह है कि मेरे ध्यान में लाया गया था sizeof(char)==1द्वारा परिभाषा C ++। इसलिए, एक "बूलियन" डेटा प्रकार का पता पता योग्य मेमोरी की सबसे छोटी इकाई से जुड़ा होता है (मेरी बात को पुष्ट करता है)।


इस बारे में आपके द्वारा छोड़ी गई सभी टिप्पणियों के लिए, यह प्रभावशाली है कि आपने उत्तर के सबसे महत्वपूर्ण भाग को छोड़ दिया: एक boolप्रकार आवंटन योग्य स्मृति की सबसे छोटी इकाई का अनुसरण करता है क्योंकि C ++ के लिए यह आवश्यक है कि इसके लिए संकेत बनाना संभव हो । उस आवश्यकता के बिना, एक boolबोधगम्य को वर्तमान बाइट-पता योग्य मशीनों पर भी एक बिट के रूप में प्रतिनिधित्व किया जा सकता है।
जुलफ

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

2
हां, और उस प्रणाली पर, एक बूल को एक सा बनाया जा सकता है। लेकिन ओपी ने यह नहीं पूछा कि "बल्ड 8 बिट्स जेफ्लूप्स काल्पनिक सीपीयू पर चौड़ा क्यों है"। उन्होंने वर्तमान, सामान्य, रोजमर्रा के सीपीयू और उन लोगों के बारे में पूछा, ऐसा इसलिए है क्योंकि वे बाइट-एड्रेसेबल हैं।
जालफ

4
sizeof (char) == 1 प्रति परिभाषा C ++ में, इसलिए आपका हार्डवेयर क्या कर सकता है या नहीं कर सकता, यह प्रासंगिक नहीं है। आपके पास sizeof (बूल) <sizeof (char) नहीं हो सकता। BTW C ++ को इस तरह से परिभाषित किया गया है कि आप हार्डवेयर को संबोधित कर सकते हैं जो कि हार्डवेयर को संबोधित कर सकता है, अगर छोटी से छोटी हार्डवेयर पता करने योग्य इकाई को चार्ज करने के लिए सुविधाजनक नहीं है, तो "वसा" सूचक हो सकता है। इसका उपयोग कम से कम कुछ सी कंपाइलरों में पुराने शब्द पते योग्य आर्किटेक्चर के लिए किया गया है।
एपीग्रामग्राम

@APgramgram:: sizeof(char)==1 definitionयह मेरे तर्क के लिए सबसे अच्छा प्रतिवाद है। धन्यवाद!
jldupont

6

8-बिट्स के बारे में जो जवाब सबसे छोटी मात्रा में है, जो पता योग्य है, सही हैं। हालांकि, कुछ भाषाएं एक तरह से बूलियंस के लिए 1-बिट का उपयोग कर सकती हैं। मुझे लगता है कि पास्कल के सेटों को बिट स्ट्रिंग्स के रूप में याद किया जा रहा है। वह निम्नलिखित सेट के लिए है:

{1, 2, 5, 7}

आपकी स्मृति में यह हो सकता है:

01100101

आप निश्चित रूप से, यदि आप चाहें तो C / C ++ में कुछ ऐसा ही कर सकते हैं। (यदि आप बूलियंस के एक झुंड का ट्रैक रख रहे हैं, तो यह समझ में आ सकता है, लेकिन यह वास्तव में स्थिति पर निर्भर करता है।)


8
वास्तव में, C ++ विशिष्ट कंटेनर वेक्टर <bool> के साथ ऐसा करता है - यह आमतौर पर एक आपदा के रूप में देखा जाता है।

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

@ नील: इसे आमतौर पर आपदा के रूप में क्यों देखा जाता है? क्या यह एक प्रदर्शन समस्या है?
Jérôme

2
@ जीनोम: ऐसा इसलिए है, क्योंकि थोड़ा सा पता योग्य नहीं है, यह नियमित रूप से व्यवहार नहीं कर सकता है vector। यह वास्तव में एसटीएल-प्रकार का कंटेनर नहीं है, क्योंकि व्यवहार पर अड़चनें हैं। इससे भी बुरी बात यह है कि यह किसी के साथ समस्याएं पैदा करता है boolऔर vectorउनमें से एक बनाना चाहता है । यह आश्चर्यजनक व्यवहार है, और यही वह नहीं है जो आप किसी भाषा में चाहते हैं।
डेविड थॉर्नले

1
@jldupont - एक बार इस तरह एक बिंदु बनाने के लिए पर्याप्त है। और सी ++ कोई गारंटी नहीं देता है कि बिट्स पता करने योग्य हैं (बल्कि रिवर्स), कोई फर्क नहीं पड़ता कि हार्डवेयर क्या सक्षम है।

1

मुझे पता है कि यह पुराना है लेकिन मुझे लगा कि मैं अपने 2 सेंट में फेंक दूंगा।

यदि आप अपने बूलियन या डेटा प्रकार को एक बिट तक सीमित करते हैं, तो आपके एप्लिकेशन को मेमोरी कर्फ्यू का खतरा है। आप स्मृति में त्रुटि आँकड़े कैसे संभालते हैं जो केवल एक बिट लंबा है?

मैं एक नौकरी के लिए इंटरव्यू के लिए गया था और उनमें से एक कार्यक्रम लीड ने मुझसे कहा था, "जब हम एक मिसाइल लॉन्च करने के लिए सिग्नल भेजते हैं तो हम वायरलेस के माध्यम से एक बिट बिट पर एक साधारण सा भेजते हैं। एक बिट भेजना अत्यधिक तेज़ होता है और हम। जितनी जल्दी हो सके उस सिग्नल की जरूरत है। ”

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


नया प्रश्न पूछें , अन्य प्रश्नों के उत्तर के रूप में अपना प्रश्न पोस्ट न करें।
इगोर जेरोसमिक

6
मुझे लगता है कि इस "उत्तर" में निहित प्रश्न वास्तव में एक बयानबाजी है, अर्थात हम बूलियंस को एक बिट के रूप में लागू नहीं करते हैं क्योंकि एक बिट त्रुटि त्रुटियों को संभाल नहीं सकता है।
स्टीफन होल्ट

1
@StephenHolt लेकिन वह कारण नहीं है और टीबीएच इस जवाब का कोई मतलब नहीं है।
डॉक्‍टर

1
...क्या? मुझे नहीं पता कि आप "एरर स्टैटिस्टिक्स" से क्या मतलब है, क्या सीआरसी या इस तरह के, या ट्रेप निरूपण। लेकिन किसी भी मामले में, यहां तक ​​कि बड़े प्रकार भी "त्रुटि आंकड़ों" के लिए अपने अतिरिक्त, 'अतिरिक्त' बिट्स का उपयोग नहीं करते हैं, लेकिन सभी चरम-पर्यावरण कोडर्स सही मान लेते हैं कि उनके कोड में मेमोरी पढ़ने से पहले उनका हार्डवेयर त्रुटि का पता लगाने / सुधार को संभाल सकता है, इसलिए वे सत्यापन सूचना या जो भी हो, हर चर को किसी भी तरह से अपना समय व्यतीत करने की आवश्यकता नहीं है। यही कारण है कि boolओपी की मशीन पर 8 बिट्स और मेरा पर 32 का उपयोग नहीं होता है , क्योंकि अन्य 7 या 31 बिट्स का उपयोग निश्चित रूप से किसी भी "त्रुटि आँकड़े" के लिए नहीं किया जाता है। इसका कोई मतलब नहीं है
अंडरस्कोर_ड

1

कुछ एम्बेडेड कंपाइलर में एक int1 प्रकार होता है जो बिट-पैक बूलियन झंडे (उदाहरण के लिए माइक्रोचिप MPU के लिए C संकलक की CCS श्रृंखला) के लिए उपयोग किया जाता है। इन चर की स्थापना, समाशोधन और परीक्षण करना एकल-निर्देश बिट-स्तर के निर्देशों का उपयोग करता है, लेकिन संकलक किसी अन्य संचालन (जैसे चर का पता लेने) को अनुमति नहीं देगा, अन्य उत्तरों में नोट किए गए कारणों के लिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.