C / C ++ संरचनाओं को डॉट करते हैं

मैं हाल ही में C / C ++ संरचनाओं - संरचना से परिचित हुआ। प्रभु, हाँ, "उन्हें जानने के लिए क्या है," आप कहते हैं? इस प्रकार, आप तुरंत 2 गलतियाँ करेंगे: पहला, मैं भगवान नहीं हूँ , और दूसरी बात, मैंने यह भी सोचा कि संरचनाएँ अफ्रीका में भी हैं। लेकिन जैसा कि यह निकला - नहीं। मैं कुछ महत्वपूर्ण विवरणों के बारे में बात करूंगा जो कुछ पाठकों को प्रति घंटे डिबगिंग से बचाएगा ...

स्मृति में फ़ील्ड्स का संरेखण

संरचना पर ध्यान दें:

struct Foo { char ch; int value; }; 

ठीक है, सबसे पहले, स्मृति में इस संरचना का आकार क्या है? sizeof(Foo) ?
स्मृति में इस संरचना का आकार संकलक सेटिंग्स पर और आपके कोड में निर्देशों पर निर्भर करता है ...

सामान्य तौर पर, खेतों को सीमा के साथ स्मृति में संरेखित किया जाता है जो अपने स्वयं के आकार का एक बहु है। यही है, 1-बाइट फ़ील्ड को संरेखित नहीं किया गया है, 2-बाइट फ़ील्ड को भी पदों से संरेखित किया गया है, 4-बाइट फ़ील्ड चार के गुणक हैं, आदि। ज्यादातर मामलों में (या मान लें कि आज यह है) स्मृति में संरचना के आकार का संरेखण 4 बाइट्स है। तो sizeof(Foo) == 8 । अतिरिक्त बाइट्स कहाँ और कैसे चिपकेंगे? यदि आप नहीं जानते हैं, तो आप कभी भी अनुमान नहीं लगाएंगे ...

• 1 बाइट: ch
• 2 बाइट्स: खाली
• 3 बाइट्स: खाली
• 4 बाइट्स: खाली
• 5 बाइट्स: मूल्य [0]
• 6 बाइट्स: मूल्य [1]
• 7 बाइट्स: मूल्य [2]
• 8 बाइट्स: मूल्य [3]

आइए अब निम्नलिखित संरचना की स्मृति में प्लेसमेंट देखें:

 struct Foo { char ch; short id; int value; }; 

यह इस तरह दिखता है:

• 1 बाइट: ch
• 2 बाइट्स: खाली
• 3 बाइट्स: आईडी [0]
• 4 बाइट्स: आईडी [1]
• 5 बाइट्स: मूल्य [0]
• 6 बाइट्स: मूल्य [1]
• 7 बाइट्स: मूल्य [2]
• 8 बाइट्स: मूल्य [3]

यही है, 4 बाइट्स द्वारा संरेखण के लिए क्या देखा जा सकता है - एक धमाके के साथ shoved (स्मृति में संरचना के आकार में वृद्धि के बिना), एक और फ़ील्ड जोड़ें:

 struct Foo { char ch; short id; short opt; int value; }; 

आइए स्मृति में फ़ील्ड के स्थान को देखें:

• 1 बाइट: ch
• 2 बाइट्स: खाली
• 3 बाइट्स: आईडी [0]
• 4 बाइट्स: आईडी [1]
• 5 बाइट्स: ऑप्ट [0]
• 6 बाइट्स: ऑप्ट [1]
• 7 बाइट्स: खाली
• 8 बाइट्स: खाली
• 9 बाइट्स: मूल्य [0]
• 10 बाइट्स: मूल्य [1]
• 11 बाइट्स: मूल्य [2]
• 12 बाइट्स: मूल्य [3]

यह सब ओह कितना दुखद है, लेकिन कोड से सीधे निपटने का एक तरीका है:

 #pragma pack(push, 1) struct Foo { // ... }; #pragma pack(pop) 

हमने संरेखण आकार को 1 बाइट पर सेट किया, संरचना का वर्णन किया, और पिछली सेटिंग पर वापस लौटा। पिछली सेटिंग पर लौटें - दृढ़ता से अनुशंसा करें। अन्यथा, सब कुछ बहुत बुरी तरह से समाप्त हो सकता है। मैं एक बार यह था - क्यूटी गिर गया। कहीं उसने उन्हें .ह-निक से नीचे ढकेला है।-निक ...

बिट क्षेत्र

टिप्पणियों में, उन्होंने मुझे बताया कि मानक के अनुसार संरचनाओं में बिट फ़ील्ड "कार्यान्वयन परिभाषित" हैं - इसलिए उनके उपयोग से बचने के लिए बेहतर है, लेकिन मेरे लिए प्रलोभन बहुत महान है ...

ऐसा नहीं है कि मैं दिल से असहज महसूस करता हूं, लेकिन सामान्य तौर पर जब मैं इस तरह से मास्क और शिफ्ट्स की मदद से बिट फ़ील्ड्स को भरने के कोड में देखता हूं तो यह बहुत ही चमकदार हो जाता है:

 unsigned field = 0x00530000; // ... field &= 0xFFFF00FF; field |= (id) << 8; // ... field &= 0xFFFFFF83; field |= (proto) << 2; 

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

आप इस कोड को कैसे पसंद करते हैं:

 #pragma pack(push,1) struct IpHeader { uint8_t header_length:4; uint8_t version:4; uint8_t type_of_service; uint16_t total_length; uint16_t identificator; // Flags uint8_t _reserved:1; uint8_t dont_fragment:1; uint8_t more_fragments:1; uint8_t fragment_offset_part1:5; uint8_t fragment_offset_part2; uint8_t time_to_live; uint8_t protocol; uint16_t checksum; // ... }; #pragma pack(pop) 

और फिर कोड में हम फ़ील्ड के साथ काम कर सकते हैं क्योंकि हम हमेशा C / C ++ में फ़ील्ड के साथ काम करते हैं। सभी पाली में काम करते हैं, आदि। संकलक पर कब्जा कर लेता है। बेशक, कुछ प्रतिबंध हैं ... जब आप एक भौतिक क्षेत्र से संबंधित एक पंक्ति में कई बिट फ़ील्ड को सूचीबद्ध करते हैं (मेरा मतलब उस प्रकार से है जो बिट फ़ील्ड नाम के बाईं ओर है) - फ़ील्ड के अंत तक सभी बिट्स के लिए नाम निर्दिष्ट करें, अन्यथा आप इन बिट्स तक नहीं पहुंच पाएंगे दूसरे शब्दों में, एक कोड होगा:

 #pragma pack(push,1) stuct MyBitStruct { uint16_t a:4; uint16_t b:4; uint16_t c; }; #pragma pack(pop) 

परिणामी संरचना 4 बाइट्स है! पहली बाइट के दो हिस्सों में खेत a और b । दूसरा बाइट नाम से उपलब्ध नहीं है और अंतिम 2 बाइट्स c नाम से उपलब्ध हैं। यह बहुत खतरनाक क्षण है। जब आप बिट फ़ील्ड के साथ संरचना का वर्णन करते हैं, तो इसके sizeof जांच करना सुनिश्चित करें!

इसके अलावा, जिस क्रम में बिट पेन को बाइट में रखा जाता है, वह बाइट क्रम पर निर्भर करता है। आदेश LITTLE_ENDIAN के साथ, बिट फ़ील्ड को पहले बाइट्स से शुरू करके वितरित किया जाता है, इसके विपरीत BIG_ENDIAN ...

बाइट क्रम

मैं कोड में htons() , ntohs() , htonl() , nthol() C ++ कोड में भी दुखी हूं। C में, यह अभी भी मान्य है, लेकिन C ++ में नहीं। मैं इसके साथ कभी नहीं डालूँगा! ध्यान दें कि निम्नलिखित सभी C ++ पर लागू होते हैं!

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

 #pragma pack(push,1) struct IpHeader { uint8_t header_length:4; uint8_t version:4; uint8_t type_of_service; u16be total_length; u16be identificator; // Flags uint8_t _reserved:1; uint8_t dont_fragment:1; uint8_t more_fragments:1; uint8_t fragment_offset_part1:5; uint8_t fragment_offset_part2; uint8_t time_to_live; uint8_t protocol; u16be checksum; // ... }; #pragma pack(pop) 

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

"सी ++ भाषा इतनी जटिल है कि हमें इसे बस लिखने की अनुमति है" © विचित्र रूप से पर्याप्त - मैं

ZY मैं अपने दृष्टिकोण से, टीसीपी / आईपी स्टैक के प्रोटोकॉल हेडर के साथ काम करने के लिए संरचनाओं को आदर्श बनाने के लिए निम्नलिखित लेखों में से एक में योजना बनाता हूं। डिसूडे - इससे पहले कि बहुत देर हो जाए!