... टेम्प्लेट पैरामीटर के मूल्यों के आधार पर विभिन्न सामग्रियों के साथ एक टेम्पलेट वर्ग कैसे भरें?

एक बार काफी समय के लिए, डी भाषा को "सही सी ++" के रूप में बनाया जाना शुरू किया गया था, सी ++ में प्राप्त अनुभव को ध्यान में रखते हुए। समय के साथ, D, C ++ से कम जटिल और अधिक अभिव्यंजक भाषा नहीं बन गया है। और पहले से ही सी ++ डी पर जासूसी करना शुरू कर दिया था। उदाहरण के लिए, सी ++ 17 में दिखाई दिया if constexpr , मेरी राय में, डी से प्रत्यक्ष उधार है, जिसका प्रोटोटाइप डी-शर्नी स्थिर था।

दुर्भाग्यवश, if constexpr C ++ में if constexpr की समान शक्ति नहीं है, static if डी। में इसके कारण हैं, लेकिन फिर भी ऐसे मामले हैं जब आप केवल इस बात पर पछता सकते हैं कि if constexpr C ++ में if constexpr आपको C + की सामग्री को नियंत्रित करने की अनुमति नहीं देता है। + वर्ग। मैं इनमें से एक मामले पर बात करना चाहूंगा।

हम इस बारे में बात करेंगे कि एक खाका वर्ग कैसे बनाया जाता है, जिसकी सामग्री (अर्थात विधियों की संरचना और कुछ विधियों का तर्क) इस टेम्पलेट वर्ग के लिए क्या पैरामीटर पारित किए गए थे, उसके आधार पर बदल जाएगा। एक उदाहरण को वास्तविक जीवन से लिया गया है, जो कि SObjectizer के नए संस्करण को विकसित करने के अनुभव से है।

हल किया जाने वाला कार्य

संदेश ऑब्जेक्ट्स को संग्रहीत करने के लिए "स्मार्ट पॉइंटर" का एक चतुर संस्करण बनाना आवश्यक है। ताकि आप कुछ इस तरह लिख सकें:

 message_holder_t<my_message> msg{ new my_message{...} }; send(target, msg); send(another_target, msg); 

इस message_holder_t क्लास की ट्रिक यह है कि विचार करने के लिए तीन महत्वपूर्ण कारक हैं।

संदेश किस प्रकार से विरासत में मिला है?

संदेश के प्रकार जो message_holder_t को पैरामीटर करते हैं, उन्हें दो समूहों में विभाजित किया जाता है। पहला समूह ऐसे संदेश हैं जो विशेष प्रकार के message_t से विरासत में मिले हैं। उदाहरण के लिए:

 struct so5_message final : public so_5::message_t { int a_; std::string b_; std::chrono::milliseconds c_; so5_message(int a, std::string b, std::chrono::milliseconds c) : a_{a}, b_{std::move(b)}, c_{c} {} }; 

इस स्थिति में, संदेश_धारक_ के अंदर केवल इस प्रकार के ऑब्जेक्ट के लिए एक संकेतक होना चाहिए। एक ही पॉइंटर को गेट्टर विधियों में वापस किया जाना चाहिए। वह यह है कि message_t से उत्तराधिकारी के मामले के लिए message_t ऐसा कुछ होना चाहिए:

 template<typename M> class message_holder_t { intrusive_ptr_t<M> m_msg; public: ... const M * get() const noexcept { return m_msg.get(); } }; 

दूसरा समूह उन उपयोगकर्ता प्रकारों का संदेश है जो message_t से विरासत में नहीं मिले हैं। उदाहरण के लिए:

 struct user_message final { int a_; std::string b_; std::chrono::milliseconds c_; user_message(int a, std::string b, std::chrono::milliseconds c) : a_{a}, b_{std::move(b)}, c_{c} {} }; 

SObjectizer में इस प्रकार के उदाहरण स्वयं द्वारा नहीं भेजे जाते हैं, लेकिन एक विशेष आवरण, user_type_message_t<M> में संलग्न होते हैं, जो पहले से message_t से विरासत में मिला है। इसलिए, ऐसे प्रकारों के लिए, message_holder_t इसके अंदर user_type_message_t<M> सूचक होना चाहिए, और user_type_message_t<M> विधियों को M को एक सूचक वापस करना होगा:

 template<typename M> class message_holder_t { intrusive_ptr_t<user_type_message_t<M>> m_msg; public: ... const M * get() const noexcept { return std::addressof(m_msg->m_payload); } }; 

संदेशों की प्रतिरक्षा या परिवर्तनशीलता

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

 message_holder_t<so5_message> msg1{...}; //  . const int a = msg1->a_; // OK. msg1->a_ = 0; //     ! message_holder_t<mutable_msg<user_message>> msg2{...}; //  . const int a = msg2->a_; // OK. msg2->a_ = 0; // OK. 

shared_ptr बनाम unique_ptr

तीसरा कारक एक स्मार्ट पॉइंटर के रूप में message_holder_t के व्यवहार का तर्क है। एक बार इसे std::shared_ptr , जैसे व्यवहार करना चाहिए आपके पास एक ही संदेश उदाहरण के लिए कई संदेश_होल्डर हो सकते हैं। और एक बार इसे std::unique_ptr , जैसे व्यवहार करना चाहिए केवल एक मैसेज_होल्डर इंस्टेंस एक मैसेज इंस्टेंस को संदर्भित कर सकता है।

डिफ़ॉल्ट रूप से, message_holder_t का व्यवहार संदेश की परिवर्तनशीलता / अपरिवर्तनीयता पर निर्भर होना चाहिए। यानी अपरिवर्तनीय संदेशों के साथ, message_holder_t को std::shared_ptr तरह व्यवहार करना चाहिए std::shared_ptr और std::shared_ptr std::unique_ptr जैसे std::unique_ptr :

 message_holder_t<so5_message> msg1{...}; message_holder_t<so5_message> msg2 = msg; // OK. message_holder_t<mutable_msg<user_message>> msg3{...}; message_holder_t<mutable_msg<user_message>> msg4 = msg3; // !  ! message_holder_t<mutable_msg<user_message>> msg5 = std::move(msg3); // OK. 

लेकिन जीवन एक जटिल चीज है, इसलिए आपको message_holder_t व्यवहार को मैन्युअल रूप से सेट करने में सक्षम होना चाहिए। ताकि आप एक अपरिवर्तनीय संदेश के लिए मैसेज_होल्डर बना सकें जो अनूठे_प्रात की तरह व्यवहार करता है। और ताकि आप एक साझा संदेश के लिए message_holder बना सकें जो साझा_प्रात की तरह व्यवहार करता है:

 using unique_so5_message = so_5::message_holder_t< so5_message, so_5::message_ownership_t::unique>; unique_so5_message msg1{...}; unique_so5_message msg2 = msg1; // !  ! unique_so5_message msg3 = std::move(msg); // OK,   msg3. using shared_user_messsage = so_5::message_holder_t< so_5::mutable_msg<user_message>, so_5::message_ownership_t::shared>; shared_user_message msg4{...}; shared_user_message msg5 = msg4; // OK. 

तदनुसार, जब message_holder_t साझा_ptr की तरह काम करता है, तो इसके पास निर्माणकर्ताओं और असाइनमेंट ऑपरेटरों का सामान्य सेट होना चाहिए: प्रतिलिपि और चाल दोनों। इसके अलावा, एक निरंतर make_reference विधि होनी चाहिए, जो make_reference अंदर message_holder_t पॉइंटर की कॉपी लौटाती है।

लेकिन जब message_holder_t unique_ptr की तरह काम करता है, तो इसके लिए कंस्ट्रक्टर और कॉपी ऑपरेटर को प्रतिबंधित किया जाना चाहिए। और make_reference मेथड को message_holder_t ऑब्जेक्ट से पॉइंटर लेना चाहिए: make_reference को कॉल करने के बाद make_reference ओरिजिनल message_holder_t खाली रहना चाहिए।

थोड़ा और औपचारिक

तो, आपको एक टेम्पलेट क्लास बनाने की आवश्यकता है:

 template< typename M, message_ownership_t Ownership = message_ownership_t::autodetected> class message_holder_t {...}; 

जिसमें:

• अंदर संग्रहीत किया जाना चाहिए intrusive_ptr_t<M> या intrusive_ptr<user_type_message_t<M>> इस बात पर निर्भर करता है कि M को message_t से विरासत में मिला है;
• संदेश की पारस्परिकता / अपरिवर्तनीयता के आधार पर, गेट मेथड्स को या तो const M* या M* को वापस करना होगा;
• कंस्ट्रक्टर और कॉपी / मूव ऑपरेटर्स का एक पूरा सेट होना चाहिए, या केवल एक कंस्ट्रक्टर और मूव ऑपरेटर होना चाहिए;
• make_reference() विधि को या तो संग्रहीत intrusive_ptr की एक प्रति वापस करनी चाहिए, या उसे intrusive_ptr का मान लेना चाहिए और मूल message_holder_t खाली छोड़ देना चाहिए। पहले मामले में, make_reference() निरंतर होना चाहिए, दूसरे में - गैर-स्थिर विधि।

सूची से अंतिम दो आइटम ओनरशिप पैरामीटर (और साथ ही autodetected के स्वामित्व के लिए उपयोग किए जाने पर संदेश की autodetected ) द्वारा निर्धारित किए जाते हैं।

यह कैसे तय किया गया

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

त्याग

नीचे दिखाया गया समाधान सुंदर, आदर्श या रोल मॉडल होने का दिखावा नहीं करता है। यह समय सीमा के दबाव में पाया गया, कार्यान्वित, परीक्षण और प्रलेखित। शायद अगर अधिक समय था, और अधिक एक समाधान खोजने में लगे हुए थे युवा आधुनिक सी ++ डेवलपर में समझदार और जानकार, यह अधिक कॉम्पैक्ट, सरल और अधिक समझने योग्य होगा। लेकिन, जैसा कि यह निकला, यह हुआ ... "सामान्य रूप से पियानोवादक को गोली मत चलाना"।

कदम और तैयार टेम्पलेट जादू की अनुक्रम

इसलिए, हमें कई तरीकों के साथ एक वर्ग रखने की आवश्यकता है। इन किटों की सामग्री कहीं से आनी चाहिए। कहाँ से?

डी में, हम static if उपयोग कर सकते हैं और static if विभिन्न स्थितियों के आधार पर कक्षा के विभिन्न भागों को परिभाषित करते हैं। कुछ रूबी में, हम शामिल विधि का उपयोग करके अपनी कक्षा में विधियों को मिला सकते हैं । लेकिन हम C ++ में हैं, जहां अब तक हमारी संभावनाएं बहुत सीमित हैं: हम या तो सीधे वर्ग के अंदर एक विधि / विशेषता को परिभाषित कर सकते हैं, या हम कुछ आधार वर्ग से विधि / विशेषता को प्राप्त कर सकते हैं।

हम कुछ शर्त के आधार पर वर्ग के अंदर विभिन्न तरीकों / विशेषताओं को परिभाषित नहीं कर सकते, क्योंकि C ++ if constexpr एक D static if । नतीजतन, केवल विरासत बनी हुई है।

Upd। जैसा कि टिप्पणियों में सुझाया गया है, मुझे यहां अधिक सावधानी से बोलना चाहिए। चूंकि C ++ में SFINAE है, इसलिए हम SFINAE के माध्यम से कक्षा में अलग-अलग तरीकों की दृश्यता को सक्षम / अक्षम कर सकते हैं (यानी, static if समान प्रभाव प्राप्त कर सकते हैं)। लेकिन इस दृष्टिकोण में दो गंभीर हैं, मेरी राय में, कमियों। सबसे पहले, अगर इस तरह के तरीके 1-2-3 नहीं हैं, लेकिन 4-5 या अधिक हैं, तो उनमें से प्रत्येक को SFINAE का उपयोग करके प्रारूपित करना थकाऊ है, और यह कोड की पठनीयता को प्रभावित करता है। दूसरे, SFINAE हमें क्लास की विशेषताओं (फ़ील्ड्स) को जोड़ने / हटाने में मदद नहीं करता है।

C ++ में, हम कई आधार वर्गों को परिभाषित कर सकते हैं जिनसे हम तब message_holder_t इनहेरिट करेंगे। और एक या दूसरे आधार वर्ग का चुनाव पहले से ही टेम्पलेट मापदंडों के मूल्यों के आधार पर किया जाएगा, std :: सशर्त का उपयोग करके।

लेकिन चाल यह है कि हमें केवल आधार वर्गों के एक सेट की आवश्यकता नहीं है, बल्कि विरासत की एक छोटी श्रृंखला है। इसकी शुरुआत में एक वर्ग होगा जो सामान्य कार्यक्षमता का निर्धारण करेगा जो किसी भी मामले में आवश्यक होगा। अगला बेस क्लास होगा जो "स्मार्ट पॉइंटर" के व्यवहार के तर्क को निर्धारित करेगा। और फिर एक वर्ग होगा जो आवश्यक गेटर्स निर्धारित करता है। इस क्रम में हम कार्यान्वित वर्गों पर विचार करेंगे।

हमारा कार्य इस तथ्य से सरल है कि सोबिजाइज़र के पास पहले से तैयार टेम्प्लेट मैजिक है जो यह निर्धारित करता है कि संदेश मैसेज_ट से विरासत में मिला है या नहीं , साथ ही मैसेज म्यूटेबिलिटी चेक करने के लिए भी है । इसलिए, कार्यान्वयन में, हम बस इस तैयार किए गए जादू का उपयोग करेंगे और इसके काम के विवरण में गोता नहीं लगाएंगे।

आम सूचक भंडारण आधार

आइए एक सामान्य आधार प्रकार से शुरू करें जो संबंधित intrusive_ptr को संग्रहीत करता है, और यह भी एक सामान्य सेट प्रदान करता है जो किसी भी message_holder_t कार्यान्वयन की आवश्यकता है:

 template< typename Payload, typename Envelope > class basic_message_holder_impl_t { protected : intrusive_ptr_t< Envelope > m_msg; public : using payload_type = Payload; using envelope_type = Envelope; basic_message_holder_impl_t() noexcept = default; basic_message_holder_impl_t( intrusive_ptr_t< Envelope > msg ) noexcept : m_msg{ std::move(msg) } {} void reset() noexcept { m_msg.reset(); } [[nodiscard]] bool empty() const noexcept { return static_cast<bool>( m_msg ); } [[nodiscard]] operator bool() const noexcept { return !this->empty(); } [[nodiscard]] bool operator!() const noexcept { return this->empty(); } }; 

इस टेम्पलेट वर्ग के दो पैरामीटर हैं। पहला, पेलोड, उस प्रकार को सेट करता है जिसे गेट्टर विधियों का उपयोग करना चाहिए। जबकि दूसरा, लिफ़ाफ़ा, intrusive_ptr के लिए प्रकार सेट करता है। मामले में जब संदेश प्रकार message_t से विरासत में मिला है message_t तो इन दोनों मापदंडों का समान मूल्य होगा। लेकिन यदि संदेश message_t से विरासत में नहीं मिला है, तो संदेश प्रकार का उपयोग पेलोड के रूप में किया जाएगा, और user_type_message_t<Payload> को लिफाफे के रूप में user_type_message_t<Payload> जाएगा।

मुझे लगता है कि मूल रूप से इस वर्ग की सामग्री सवाल नहीं उठाती है। लेकिन दो बातों पर अलग से ध्यान दिया जाना चाहिए।

सबसे पहले, सूचक खुद, अर्थात्। m_msg विशेषता को संरक्षित अनुभाग में परिभाषित किया गया है ताकि वर्गों के वारिसों तक इसकी पहुंच हो।

दूसरे, इस वर्ग के लिए, कंपाइलर ही सभी आवश्यक कंस्ट्रक्टर और कॉपी / ऑपरेट ऑपरेटरों को उत्पन्न करता है। और इस वर्ग के स्तर पर, हम अभी तक कुछ भी निषिद्ध नहीं करते हैं।

शेयर्ड_एप्ट्र और यूनिक_प्रेट व्यवहार के लिए अलग-अलग आधार

तो, हमारे पास एक वर्ग है जो एक संदेश के लिए एक पॉइंटर को संग्रहीत करता है। अब हम इसके उत्तराधिकारियों को परिभाषित कर सकते हैं, जो या तो share_ptr के रूप में या अनूठे_ptr के रूप में व्यवहार करेंगे।

चलिए साझा करें_शेष व्यवहार के मामले से शुरू करते हैं, क्योंकि यहाँ सबसे कम कोड है:

 template< typename Payload, typename Envelope > class shared_message_holder_impl_t : public basic_message_holder_impl_t<Payload, Envelope> { using direct_base_type = basic_message_holder_impl_t<Payload, Envelope>; public : using direct_base_type::direct_base_type; [[nodiscard]] intrusive_ptr_t< Envelope > make_reference() const noexcept { return this->m_msg; } }; 

कुछ भी जटिल नहीं है: basic_message_holder_impl_t से basic_message_holder_impl_t , इसके सभी basic_message_holder_impl_t को विरासत में मिला है, और make_reference() एक सरल, गैर-विनाशकारी कार्यान्वयन परिभाषित करता है।

अनूठे_ व्यवहार के मामले के लिए, कोड बड़ा है, हालांकि इसमें कुछ भी जटिल नहीं है:

 template< typename Payload, typename Envelope > class unique_message_holder_impl_t : public basic_message_holder_impl_t<Payload, Envelope> { using direct_base_type = basic_message_holder_impl_t<Payload, Envelope>; public : using direct_base_type::direct_base_type; unique_message_holder_impl_t( const unique_message_holder_impl_t & ) = delete; unique_message_holder_impl_t( unique_message_holder_impl_t && ) = default; unique_message_holder_impl_t & operator=( const unique_message_holder_impl_t & ) = delete; unique_message_holder_impl_t & operator=( unique_message_holder_impl_t && ) = default; [[nodiscard]] intrusive_ptr_t< Envelope > make_reference() noexcept { return { std::move(this->m_msg) }; } }; 

फिर, हम basic_message_holder_impl_t से विरासत में प्राप्त करते हैं और हमारे द्वारा basic_message_holder_impl_t को विरासत में देते हैं (यह डिफ़ॉल्ट निर्माता और प्रारंभिक निर्माता है)। लेकिन एक ही समय में, हम यूनिक_प्रेट लॉजिक के अनुसार कंस्ट्रक्टर और कॉपी / मूव ऑपरेटर्स को परिभाषित करते हैं: हम नकल पर रोक लगाते हैं, हम इस कदम को लागू करते हैं।

हमारे पास यहां एक विध्वंसक make_reference() विधि भी make_reference() ।

वास्तव में यही सब है। यह केवल इन दो आधार वर्गों के बीच विकल्प का एहसास करने के लिए रहता है ...

Share_ptr और unique_ptr व्यवहार के बीच चयन करना

Share_ptr और unique_ptr व्यवहार के बीच चयन करने के लिए, आपको निम्नलिखित मेटाफ़ंक्शन (मेटाफ़ंक्शन) की आवश्यकता है क्योंकि यह संकलन समय में प्रकारों के साथ "काम करता है":

 template< typename Msg, message_ownership_t Ownership > struct impl_selector { static_assert( !is_signal<Msg>::value, "Signals can't be used with message_holder" ); using P = typename message_payload_type< Msg >::payload_type; using E = typename message_payload_type< Msg >::envelope_type; using type = std::conditional_t< message_ownership_t::autodetected == Ownership, std::conditional_t< message_mutability_t::immutable_message == message_mutability_traits<Msg>::mutability, shared_message_holder_impl_t<P, E>, unique_message_holder_impl_t<P, E> >, std::conditional_t< message_ownership_t::shared == Ownership, shared_message_holder_impl_t<P, E>, unique_message_holder_impl_t<P, E> > >; }; 

यह मेटाफ़ंक्शन मैसेज_होल्डर_ट पैरामीटर सूची से दोनों मापदंडों को स्वीकार करता है और, परिणामस्वरूप (जो कि नेस्टेड type की परिभाषा है), "रिटर्न" उस प्रकार का है जिसमें से यह विरासत में मिला होना चाहिए। यानी या तो shared_message_holder_impl_t या unique_message_holder_impl_t ।

impl_selector की परिभाषा के अंदर impl_selector आप ऊपर बताए गए जादू के निशान देख सकते हैं, और जो हम इसमें नहीं गए: message_payload_type<Msg>::payload_type , message_payload_type<Msg>::envelope_type message_payload_type<Msg>::payload_type और message_mutability_traits<Msg>::mutability ।

और impl_selector का उपयोग करने के लिए impl_selector आसान था, फिर हम इसके लिए एक छोटा नाम परिभाषित करेंगे:

 template< typename Msg, message_ownership_t Ownership > using impl_selector_t = typename impl_selector<Msg, Ownership>::type; 

गेटर्स के लिए बेस

तो, हमारे पास पहले से ही एक आधार का चयन करने का अवसर है जिसमें एक पॉइंटर होता है और एक "स्मार्ट पॉइंटर" के व्यवहार को परिभाषित करता है। अब हमें गेट आधार विधियों के साथ यह आधार प्रदान करने की आवश्यकता है। हमें एक साधारण वर्ग की आवश्यकता क्यों है:

 template< typename Base, typename Return_Type > class msg_accessors_t : public Base { public : using Base::Base; [[nodiscard]] Return_Type * get() const noexcept { return get_ptr( this->m_msg ); } [[nodiscard]] Return_Type & operator * () const noexcept { return *get(); } [[nodiscard]] Return_Type * operator->() const noexcept { return get(); } }; 

यह एक टेम्पलेट वर्ग है जो दो मापदंडों पर निर्भर करता है, लेकिन उनका अर्थ पूरी तरह से अलग है। बेस पैरामीटर ऊपर दिखाए गए impl_selector मेटाफ़ंक्शन का परिणाम होगा। यानी बेस पैरामीटर के रूप में, बेस क्लास सेट किया जाता है जिसमें से वारिस किया जाता है।

यह ध्यान रखना महत्वपूर्ण है कि यदि उत्तराधिकार unique_message_holder_impl_t से आता है, जिसके लिए कंस्ट्रक्टर और कॉपी ऑपरेटर निषिद्ध हैं, तो कंपाइलर msg_accessors_t लिए कंस्ट्रक्टर और कॉपी ऑपरेटर नहीं बना msg_accessors_t । जो हमें चाहिए।

संदेश का प्रकार, सूचक / लिंक जिसे गेटर्स द्वारा लौटाया जाएगा, वह Return_Type पैरामीटर के रूप में कार्य करेगा। चाल यह है कि Msg प्रकार के एक अपरिवर्तनीय संदेश के लिए Msg Return_Type पैरामीटर Msg को कसने के लिए सेट किया जाएगा। जबकि Msg प्रकार के एक परिवर्तनशील संदेश के लिए Msg पैरामीटर Return_Type के मान का मान Msg । इस प्रकार, get() const Msg* get() विधि अपरिवर्तनीय संदेशों के लिए const Msg* और Msg* लिए बस Msg* लौटा देगी।

मुफ्त फ़ंक्शन get_ptr() का उपयोग करके get_ptr() उन संदेशों के साथ काम करने की समस्या को हल करते हैं जो message_t से विरासत में नहीं मिले हैं:

 template< typename M > M * get_ptr( const intrusive_ptr_t<M> & msg ) noexcept { return msg.get(); } template< typename M > M * get_ptr( const intrusive_ptr_t< user_type_message_t<M> > & msg ) noexcept { return std::addressof(msg->m_payload); } 

यानी यदि संदेश message_t से विरासत में नहीं मिला है और user_type_message_t<Msg> रूप में संग्रहीत है, तो दूसरा अधिभार कहा जाता है। और अगर यह विरासत में मिला है, तो पहला अधिभार।

गेटर्स के लिए एक विशिष्ट आधार चुनना

तो, msg_accessors_t टेम्पलेट को दो मापदंडों की आवश्यकता है। पहले की गणना impl_selector मेटाफ़ंक्शन द्वारा की जाती है। लेकिन msg_accessors_t से एक विशिष्ट आधार प्रकार msg_accessors_t , हमें दूसरे पैरामीटर का मान निर्धारित करना होगा। इसके लिए एक और मेटाफ़ंक्शन का इरादा है:

 template< message_mutability_t Mutability, typename Base > struct accessor_selector { using type = std::conditional_t< message_mutability_t::immutable_message == Mutability, msg_accessors_t<Base, typename Base::payload_type const>, msg_accessors_t<Base, typename Base::payload_type> >; }; 

आप केवल Return_Type पैरामीटर की गणना पर ध्यान दे सकते हैं। उन कुछ मामलों में से एक जहां पूर्वी कास्ट उपयोगी है;)

ठीक है, निम्नलिखित कोड की पठनीयता बढ़ाने के लिए, इसके साथ काम करने के लिए एक अधिक कॉम्पैक्ट विकल्प:

 template< message_mutability_t Mutability, typename Base > using accessor_selector_t = typename accessor_selector<Mutability, Base>::type; 

अंतिम उत्तराधिकारी संदेश_धारक_t

अब आप देख सकते हैं कि message_holder_t क्या message_holder_t , जिसके कार्यान्वयन के लिए इन सभी बेस क्लास और मेटाफैक्शंस की आवश्यकता थी (मैसेज_होल्डर में रखे गए मैसेज की एक इंस्टेंस के निर्माण के तरीकों को लागू करने से हटा दिया जाता है):

 template< typename Msg, message_ownership_t Ownership = message_ownership_t::autodetected > class message_holder_t : public details::message_holder_details::accessor_selector_t< details::message_mutability_traits<Msg>::mutability, details::message_holder_details::impl_selector_t<Msg, Ownership> > { using base_type = details::message_holder_details::accessor_selector_t< details::message_mutability_traits<Msg>::mutability, details::message_holder_details::impl_selector_t<Msg, Ownership> >; public : using payload_type = typename base_type::payload_type; using envelope_type = typename base_type::envelope_type; using base_type::base_type; friend void swap( message_holder_t & a, message_holder_t & b ) noexcept { using std::swap; swap( a.message_reference(), b.message_reference() ); } }; 

वास्तव में, हमने जो कुछ भी ऊपर विश्लेषण किया था, उसे दो मेटाफ़ंक्शन के इस "कॉल" को रिकॉर्ड करने के लिए आवश्यक था:

 details::message_holder_details::accessor_selector_t< details::message_mutability_traits<Msg>::mutability, details::message_holder_details::impl_selector_t<Msg, Ownership> > 

क्योंकि यह पहला विकल्प नहीं है, लेकिन कोड के सरलीकरण और कमी का परिणाम है, मैं कह सकता हूं कि मेटाफ़ंक्शन के कॉम्पैक्ट रूप अच्छी तरह से कोड की मात्रा को कम करते हैं और इसकी व्यापकता को बढ़ाते हैं (यदि आम तौर पर यहां समझ की बात करना उचित है)।

और अगर होता तो क्या होता ...

लेकिन अगर C ++ में if constexpr जितना शक्तिशाली होता, static if डी में होता, तो आप कुछ इस तरह लिख सकते थे:

 template< typename Msg, message_ownership_t Ownership = message_ownership_t::autodetected > class message_holder_t { static constexpr const message_mutability_t Mutability = details::message_mutability_traits<Msg>::mutability; static constexpr const message_ownership_t Actual_Ownership = (message_ownership_t::unique == Ownership || (message_mutability_t::mutable_msg == Mutability && message_ownership_t::autodetected == Ownership)) ? message_ownership_t::unique : message_ownership_t::shared; public : using payload_type = typename message_payload_type< Msg >::payload_type; using envelope_type = typename message_payload_type< Msg >::envelope_type; private : using getter_return_type = std::conditional_t< message_mutability_t::immutable_msg == Mutability, payload_type const, payload_type >; public : message_holder_t() noexcept = default; message_holder_t( intrusive_ptr_t< envelope_type > mf ) noexcept : m_msg{ std::move(mf) } {} if constexpr(message_ownership_t::unique == Actual_Ownership ) { message_holder_t( const message_holder_t & ) = delete; message_holder_t( message_holder_t && ) noexcept = default; message_holder_t & operator=( const message_holder_t & ) = delete; message_holder_t & operator=( message_holder_t && ) noexcept = default; } friend void swap( message_holder_t & a, message_holder_t & b ) noexcept { using std::swap; swap( a.m_msg, b.m_msg ); } [[nodiscard]] getter_return_type * get() const noexcept { return get_const_ptr( m_msg ); } [[nodiscard]] getter_return_type & operator * () const noexcept { return *get(); } [[nodiscard]] getter_return_type * operator->() const noexcept { return get(); } if constexpr(message_ownership_t::shared == Actual_Ownership) { [[nodiscard]] intrusive_ptr_t< envelope_type > make_reference() const noexcept { return m_msg; } } else { [[nodiscard]] intrusive_ptr_t< envelope_type > make_reference() noexcept { return { std::move(m_msg) }; } } private : intrusive_ptr_t< envelope_type > m_msg; }; 

, . C++ :(
( C++ "" ).

, , ++. , , , . , message_holder_t . , , if constexpr .

निष्कर्ष

, C++. , . , , .

, .

, , ++ , . , . , , . , . C++98/03 , C++11 .