Rust: सी इंटरऑप के लिए बिट फ़ील्ड का समर्थन करें

अपरिहार्य लगता है। मैं पहले मैक्रो रूट को आजमाना पसंद करूंगा।

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

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

लिनक्स कर्नेल (और कई पुस्तकालय) सामान्य रूप से बिटफ़ील्ड से बचते हैं, क्योंकि संकलक की कोड पीढ़ी अविश्वसनीय है। संरेखण, क्रम और लेआउट को कार्यान्वयन पर छोड़ दिया गया है, इसलिए हमें विभिन्न एबीआई का समर्थन करना होगा: http://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html

हाँ, मैं इससे बच रहा हूँ।

क्या इसका मतलब यह है कि सर्वो में ऐसा करने के लिए हमें इन मुद्दों से बचने के लिए प्रत्येक फ़ील्ड को प्राप्त/सेट करने के लिए सी शिम्स का उपयोग करना होगा?

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

@RushPL : रस्ट मैक्रोज़ C मैक्रोज़ की तरह नहीं हैं। वे एक पाठ्य प्रतिस्थापन नहीं हैं, बल्कि पैटर्न मिलान (घोषणात्मक मैक्रोज़) या रस्ट कोड (प्रक्रियात्मक मैक्रोज़) के माध्यम से टोकन पेड़ों में हेरफेर करते हैं। कुछ मामलों में उनके बिना बेहतर सिंटैक्स प्रदान किया जा सकता है, लेकिन रस्ट पहले से ही टाइप-चेक किए गए प्रारूप स्ट्रिंग्स ( std::fmt ) जैसी सामग्री के लिए मैक्रोज़ का भारी उपयोग करता है।

ठीक है, इसमें अभी भी विशिष्ट बिट संख्याएं प्रदान करना शामिल होगा, है ना? (इसलिए कोड त्रुटि प्रवण बनाना)
let some_state = int_from_bits!(object.state, 3, 5) // 5 bit number from bit 3
बनाम
let some_state = object.some_state // compiler does all the magic as it should be

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

बिटफ़ील्ड का उपयोग न करने पर आप सी या सी ++ के साथ वही कर सकते हैं लेकिन कोड उत्पन्न कर रहा है एक अच्छा जवाब? कोई सहायक जेनरिक को छोड़ सकता है और इसके बजाय विभिन्न प्रकारों के लिए सभी कोड उत्पन्न कर सकता है। वैसे भी, डेटा संरचनाओं के आकार और एम्बेडेड फ़ील्ड के उपयोग में आसानी के बारे में परवाह करने वाले किसी व्यक्ति के परिप्रेक्ष्य से केवल मेरे 2 सेंट।

देखें: आरएफसी: बिट फ़ील्ड और बिट मिलान
https://github.com/rust-lang/rfcs/pull/29

क्या नया bitflags! मैक्रो इस समस्या का समाधान करता है?

https://github.com/mozilla/rust/pull/13072

गुनगुनी प्रतिक्रिया और अस्पष्ट आवश्यकताओं को देखते हुए, इस मुद्दे को किसी भी तरह से बंद करना समझदारी हो सकती है।

इस मुद्दे को RFCs रेपो में ले जाया गया है: rust-lang/rfcs#314