C ++ 11 के तहत लगातार अभिव्यक्तियों में जुड़ने का उपयोग करना

आप पहले से ही सामान्यीकृत स्थिर अभिव्यक्तियों से परिचित हो सकते हैं। यदि नहीं, तो आप उनके बारे में पढ़ सकते हैं, उदाहरण के लिए, यहाँ )। इस लेख में मैं निरंतर अभिव्यक्तियों में यूनियनों का उपयोग करने में अपने अनुभव को साझा करना चाहता हूं।

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

प्रस्तावना

क्या आप Boost.Optional पुस्तकालय को जानते हैं? संक्षेप में, बढ़ावा :: वैकल्पिक <टी> एक "यौगिक" इकाई है जो किसी भी प्रकार के टी प्लस एक अतिरिक्त राज्य के स्टोर कर सकता है, एक संग्रहीत मूल्य की अनुपस्थिति को दर्शाता है। यह एक अशक्त टी है।

बढ़ावा देने की सुविधाओं में से एक :: वैकल्पिक यह है कि इस ऑब्जेक्ट को "खाली" स्थिति के साथ प्रारंभ करके, टाइप टी का एक ऑब्जेक्ट बिल्कुल भी नहीं बनाया गया है। इसके डिफॉल्ट कंस्ट्रक्टर को भी नहीं कहा जाता है: सबसे पहले, प्रदर्शन को बढ़ाने के लिए, और दूसरी बात, टाइप T में एक डिफॉल्ट कंस्ट्रक्टर नहीं हो सकता है। ऐसा करने का एक तरीका यह है कि टाइप टी के ऑब्जेक्ट को स्टोर करने के लिए मेमोरी में एक बफर को आवंटित किया जाए और एक स्पष्ट कंस्ट्रक्टर कॉल का उपयोग केवल तब किया जाए जब ऑब्जेक्ट को बनाने की आवश्यकता हो।

template <typename T> class optional { bool initialized_; char storage_[ sizeof(T) ]; // ... }; 

यह संभव कार्यान्वयन के लिए विचारों में से एक है। व्यवहार में, यह संरेखण समस्याओं के कारण काम नहीं करेगा - हमें std :: align_storage का उपयोग करना होगा; आप "एक्सक्लूसिव ज्वाइन" का भी उपयोग कर सकते हैं - इस तंत्र को एसीसीयू ओवरलोड # 112 में विस्तार से वर्णित किया गया है। "खाली" राज्य और "वास्तविक मूल्य से" के निर्माता निम्नानुसार लागू किए जा सकते हैं:

 optional<T>::optional(none_t) // null-state tag { initialized_ = false; //  storage_  }; optional<T>::optional(T const& val) { new (storage_) T{val}; initialized_ = true; }; 

विध्वंसक का कार्यान्वयन, जैसा कि आपने अनुमान लगाया होगा, निम्नानुसार हो सकता है:

 optional<T>::~optional() { if (initialized_) { static_cast<T*>(storage_) -> T::~T(); } }; 

समस्या नंबर 1

एसटीडी :: वैकल्पिक का उपयोग करने के मामले में, कुछ विशेषताएं हैं। उनमें से एक तथ्य यह है कि एसटीडी :: वैकल्पिक <टी> एक शाब्दिक प्रकार होना चाहिए (जिनकी वस्तुओं को संकलन चरण में स्थिरांक के रूप में इस्तेमाल किया जा सकता है)। इन सीमाओं पर मानक स्थानों में से एक यह है कि उनके पास एक तुच्छ विध्वंसक होना चाहिए: एक विध्वंसक जो कुछ भी नहीं करता है। और जैसा कि हम ऊपर के उदाहरण में देखते हैं, हमारा विध्वंसक अभी भी कुछ आवश्यक करता है, अर्थात्, हमारा लक्ष्य आमतौर पर अप्राप्य है। यद्यपि यह विशेष मामलों के लिए प्राप्त हो सकता है (जब टाइप टी का एक विध्वंसक भी तुच्छ होता है, उदाहरण के लिए, यदि टी = इंट , हमें इसके विनाशकर्ता को कॉल करने की आवश्यकता नहीं है)। यहां से एक तुच्छ विध्वंसक की व्यावहारिक परिभाषा का अनुसरण किया जाता है: यह एक ऐसा विध्वंसक है जिसे हम बिना किसी नुकसान के कार्यक्रम में शामिल नहीं कर सकते हैं।

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

इस प्रकार, एक उपयुक्त आकार के सरणी के साथ वैकल्पिक वर्ग का हमारा कार्यान्वयन काम नहीं करेगा, क्योंकि मूल्य द्वारा निर्माणकर्ता में सदस्य प्रारंभ सूची (निर्माणकर्ता निकाय के सामने) में आरंभीकृत नहीं किया गया है। हम "खाली" राज्य के कंस्ट्रक्टर में शून्य के साथ सरणी भर सकते हैं, लेकिन रनटाइम के दौरान यह सभी ओवरहेड है। हमें std :: align_storage के साथ भी इसी तरह की समस्या होगी । और हम एक साधारण अनन्य जॉइन (ACCU ओवरलोड # 112 से) का उपयोग नहीं कर सकते

 template <typename T> class optional { bool initialized_; union { T storage_ }; //   }; 

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

समस्या संख्या 2

हमारे डिजाइन का एक अन्य लक्ष्य एक ऐसा फ़ंक्शन प्राप्त करना है जो हमारी वस्तु से इसमें टाइप किए गए T का मान निकालता है। बढ़ावा देने में :: वैकल्पिक कार्यान्वयन, प्रस्तावित std :: वैकल्पिक की तरह , ऑपरेटर "*" ( ऑपरेटर * ) का उपयोग संग्रहीत मूल्य तक पहुंचने के लिए किया जाता है। अधिकतम प्रदर्शन के लिए, हम मूल ऑब्जेक्ट की स्थिति की जांच नहीं करते हैं (इसके लिए उपयोगकर्ता एक अलग फ़ंक्शन का उपयोग कर सकता है) और सीधे टाइप टी के संग्रहीत मूल्य तक पहुंच सकता है ।

 explicit optional<T>::operator bool() const // check for being initialized { return initialized_; }; T const& optional<T>::operator*() const // precondition: bool(*this) { return *static_cast<T*>(storage_); } 

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

 constexpr explicit optional<T>::operator bool() { return initialized_; }; constexpr T const& optional<T>::operator*() { return bool(*this) ? *static_cast<T*>(storage_) : throw uninitialized_optional(); } 

लेकिन फिर भी, वह फिट नहीं है। हम वास्तव में संकलन चरण में सत्यापन प्राप्त करेंगे, लेकिन निष्पादन चरण में सत्यापन भी होगा, जो प्रदर्शन को प्रभावित करेगा। क्या संकलन चरण पर चेक को छोड़ना संभव है, लेकिन कोड निष्पादन चरण में ऐसा नहीं करना है?

निर्णय

इन दोनों समस्याओं को एक टी- प्रकार संघ और एक स्टब का उपयोग करके हल किया जाता है:

 struct dummy_t{}; template <typename T> union optional_storage { static_assert( is_trivially_destructible<T>::value, "" ); dummy_t dummy_; T value_; constexpr optional_storage() //  ""  : dummy_{} {} constexpr optional_storage(T const& v) //    : value_{v} {} ~optional_storage() = default; //   }; 

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

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

 constexpr optional_storage<int> oi{1}; // ok constexpr int i = oi.value_; // ok static_assert(i == 1, ""); // ok constexpr optional_storage<int> oj{}; // ok constexpr int j = oj.value_; //     

अब हमारे वैकल्पिक वर्ग (तुच्छ विध्वंसक प्रकारों के लिए T ) को इस तरह लागू किया जा सकता है:

 template <typename T> // requires: is_trivially_destructible<T>::value class optional { bool initialized_; optional_storage<T> storage_; public: constexpr optional(none_t) : initialized_{false}, storage_{} {} constexpr optional(T const& v) : initialized_{true}, storage_{v} {} constexpr T const& operator*() // precondition: bool(*this) { return storage_.value_; } // ... }; 

ऑपरेटर * में संकलन चरण में त्रुटि संदेश सही नहीं है: इसका मतलब यह नहीं है कि ऑब्जेक्ट को आरंभीकृत नहीं किया गया था, लेकिन केवल संघ के एक निष्क्रिय सदस्य के उपयोग को इंगित करता है। फिर भी, हमारा मुख्य लक्ष्य हासिल किया गया था: मूल्य तक गलत पहुंच वाला कोड संकलन नहीं करेगा।

आप std का मूल कार्यान्वयन पा सकते हैं :: यहाँ वैकल्पिक : github.com/akrzemi1/optional