हाल ही में, सोबिजाइज़र के एक नए संस्करण पर काम करते समय, मुझे संकलन समय में डेवलपर के कार्यों को नियंत्रित करने के कार्य के साथ सामना करना पड़ा। लब्बोलुआब यह था कि पहले एक प्रोग्रामर फॉर्म की कॉल कर सकता था:

receive(from(ch).empty_timeout(150ms), ...); receive(from(ch).handle_n(2).no_wait_on_empty(), ...); receive(from(ch).empty_timeout(2s).extract_n(20).stop_on(...), ...); receive(from(ch).no_wait_on_empty().stop_on(...), ...); 

प्राप्त () ऑपरेशन के लिए मापदंडों का एक सेट आवश्यक था, जिसके लिए तरीकों की एक श्रृंखला का उपयोग किया गया था, जैसे कि ऊपर from(ch).empty_timeout(150ms) या from(ch).handle_n(2).no_wait_on_empty() from(ch).empty_timeout(150ms) ऊपर दिखाए गए। उसी समय, हैंडल_ एन () / एक्सट्रैक्ट_एन () विधियों को कॉल करना, जो संदेशों को निकालने / संसाधित करने की संख्या को सीमित करता है, वैकल्पिक था। इसलिए, ऊपर दिखाए गए सभी चेन सही थे।

लेकिन नए संस्करण में, उपयोगकर्ता को निकालने और / या प्रक्रिया के लिए संदेशों की संख्या को स्पष्ट रूप से इंगित करने के लिए मजबूर करना आवश्यक था। यानी from(ch).empty_timeout(150ms) फ़ॉर्म की एक श्रृंखला अब गलत हो गई है। इसे from(ch).handle_all().empty_timeout(150ms) प्रतिस्थापित किया जाना चाहिए।

और मैं इसे बनाना चाहता था ताकि कंपाइलर प्रोग्रामर को हाथ से मार दे अगर प्रोग्रामर हैंडल_ल (), हैंडल_ एन (या अर्क_ एन) को कॉल करना भूल गया।

क्या C ++ इसकी मदद कर सकता है?

हां। और अगर किसी को बिल्कुल कैसे दिलचस्पी है, तो बिल्ली के नीचे आपका स्वागत है।

एक प्राप्त () फ़ंक्शन से अधिक है

प्राप्त () फ़ंक्शन को ऊपर दिखाया गया था, जिसके लिए पैरामीटर कॉल की एक श्रृंखला (जिसे बिल्डर पैटर्न भी कहा जाता है) का उपयोग करके सेट किया गया था। लेकिन एक चुनिंदा () फ़ंक्शन भी था, जिसे लगभग समान मापदंडों का सेट प्राप्त हुआ था:

 select(from_all().empty_timeout(150ms), case_(...), case_(...), ...); select(from_all().handle_n(2).no_wait_on_empty(), case_(...), case_(...), ...); select(from_all().empty_timeout(2s).extract_n(20).stop_on(...), case_(...), case_(...), ...); select(from_all().no_wait_on_empty().stop_on(...), case_(...), case_(...), ...); 

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

संभव समाधान

इसलिए, कार्य उपयोगकर्ता के लिए है असफल के बिना handle_all (), handle_n () या extract_n () को लागू करने के लिए।

सिद्धांत रूप में, यह किसी भी जटिल निर्णयों का सहारा लिए बिना प्राप्त किया जा सकता है। उदाहरण के लिए, आप चयन () और प्राप्त () के लिए एक अतिरिक्त तर्क दर्ज कर सकते हैं:

 receive(handle_all(), from(ch).empty_timeout(150ms), ...); select(handle_n(20), from_all().no_wait_on_empty(), ...); 

या उपयोगकर्ता को प्राप्त करने के लिए मजबूर करना संभव होगा () / चयन () अलग से कॉल करें:

 receive(handle_all(from(ch).empty_timeout(150ms)), ...); select(handle_n(20, from_all().no_wait_on_empty()), ...); 

लेकिन यहां समस्या यह है कि जब एसओबीजेनाइजर के नए संस्करण पर स्विच किया जाता है, तो उपयोगकर्ता को अपना कोड फिर से करना होगा। भले ही कोड, सिद्धांत रूप में, फिर से काम करने की आवश्यकता नहीं थी। इस स्थिति में कहें:

 receive(from(ch).handle_n(2).no_wait_on_empty(), ...); select(from_all().empty_timeout(2s).extract_n(20).stop_on(...), case_(...), case_(...), ...); 

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

तो CRTP कहाँ आता है?

लेख के शीर्षक में CRTP का उल्लेख किया गया है। वह उत्सुकता से आवर्ती टेम्पलेट पैटर्न भी है (जो इस दिलचस्प, लेकिन थोड़ा मस्तिष्क-सहिष्णु तकनीक से परिचित होना चाहते हैं, धाराप्रवाह सी ++ ब्लॉग पर पोस्ट की इस श्रृंखला के साथ शुरू कर सकते हैं)।

CRTP का उल्लेख किया गया था क्योंकि CRTP के माध्यम से हमने प्राप्त () और चयन () फ़ंक्शन मापदंडों के साथ काम को लागू किया था। चूंकि प्राप्त करने के लिए मापदंडों का शेर का हिस्सा () और चयन () एक ही था, कोड ने कुछ इस तरह का उपयोग किया:

 template<typename Derived> class bulk_processing_params_t { ...; //     . Derived & self_reference() { return static_cast<Derived &>(*this); } ... public: auto & handle_n(int v) { to_handle_ = v; return self_reference(); } ... auto & extract_n(int v) { to_extract_ = v; return self_reference(); } ... }; class receive_processing_params_t final : public bulk_processing_params_t<receive_processing_params_t> { ...; //   receive . }; class select_processing_params_t final : public bulk_processing_params_t<select_processing_params_t> { ...; }; 

यहाँ CRTP क्यों है?

हमें यहाँ CRTP का उपयोग करना था ताकि आधार वर्ग में परिभाषित की गई सेटर विधियाँ आधार प्रकार पर नहीं, बल्कि व्युत्पन्न एक संदर्भ में लौट सकें।

यही है, अगर यह सीआरटीपी नहीं था जो कि इस्तेमाल किया गया था, लेकिन साधारण विरासत, तो हम केवल इस तरह लिख सकते हैं:

 class bulk_processing_params_t { public: //      bulk_processing_params_t, //     . bulk_processing_params_t & handle_n(int v) {...} bulk_processing_params_t & extract_n(int v) {...} ... }; class receive_processing_params_t final : public bulk_processing_params_t { public: //      //   bulk_processing_params_t,    // receive_processing_params_t. ... //       //  receive_processing_params_t. receive_processing_params_t & receive_payload(int v) {...} }; class select_processing_params_t final : public bulk_processing_params_t { public: //      //   bulk_processing_params_t,    // select_processing_params_t. ... }; 

लेकिन इस तरह के एक आदिम तंत्र हमें एक ही बिल्डर पैटर्न का उपयोग करने की अनुमति नहीं देगा, क्योंकि:

 receive_processing_params_t{}.handle_n(20).receive_payload(0) 

संकलित नहीं। हैंडल_ एन () विधि बल्क_प्रोसेसिंग_परम__ का संदर्भ लौटाएगी, और वहाँ प्राप्त_पेयोड () विधि अभी तक परिभाषित नहीं है।

लेकिन CRTP के साथ हमें बिल्डर पैटर्न के साथ कोई समस्या नहीं है।

अंतिम निर्णय

अंतिम समाधान अंतिम प्रकारों के लिए है, जैसे कि स्वयं को टेम्पलेट प्रकार बनाने के लिए, प्राप्त_प्रोसेसिंग_परम__ और चयन_प्रोसेसिंग_परम__। ताकि उन्हें निम्न रूप के स्केलर के साथ परिमाणित किया जाए:

 enum class msg_count_status_t { undefined, defined }; 

और ताकि अंतिम प्रकार को T <msg_count_status_t :: undefined> से T <msg_count_status_t :: परिभाषित> में परिवर्तित किया जा सके।

यह, उदाहरण के लिए, प्राप्त () फ़ंक्शन में get_processing_params_t प्राप्त करने और कॉम्प-टाइम में स्थिति मान की जांच करने की अनुमति देगा। कुछ इस तरह:

 template< msg_count_status_t Msg_Count_Status, typename... Handlers > inline mchain_receive_result_t receive( const mchain_receive_params_t<Msg_Count_Status> & params, Handlers &&... handlers ) { static_assert( Msg_Count_Status == msg_count_status_t::defined, "message count to be processed/extracted should be defined " "by using handle_all()/handle_n()/extract_n() methods" ); 

सामान्य तौर पर, सब कुछ सरल है, हमेशा की तरह: लेना और करना;)

किए गए निर्णय का विवरण

आइए एक न्यूनतम उदाहरण देखें, जो कि SObjectizer की बारीकियों से अलग है, जैसा कि यह दिखता है।

इसलिए, हमारे पास पहले से ही एक प्रकार है जो यह निर्धारित करता है कि संदेशों की संख्या पर सीमा निर्धारित है या नहीं:

 enum class msg_count_status_t { undefined, defined }; 

अगला, हमें एक ऐसी संरचना की आवश्यकता है जिसमें सभी सामान्य पैरामीटर संग्रहीत किए जाएंगे:

 struct basic_data_t { int to_extract_{}; int to_handle_{}; int common_payload_{}; }; 

आम तौर पर यह मायने नहीं रखता कि बुनियादी_डेटा_टी की सामग्री क्या होगी। उदाहरण के लिए, ऊपर दिखाए गए क्षेत्रों का न्यूनतम सेट उपयुक्त है।

Basic_data_t के संबंध में, यह महत्वपूर्ण है कि विशिष्ट परिचालनों के लिए (चाहे इसे प्राप्त किया जाए), चयन करें (), या कुछ और), इसका स्वयं का ठोस प्रकार बनाया जाएगा जो basic_data_t को विरासत में मिले। उदाहरण के लिए, हमारे अमूर्त उदाहरण में प्राप्त () के लिए, यह निम्नलिखित संरचना होगी:

 struct receive_specific_data_t final : public basic_data_t { int receive_payload_{}; receive_specific_data_t() = default; receive_specific_data_t(int v) : receive_payload_{v} {} }; 

हम मानते हैं कि बुनियादी_डेटा_ संरचना और इसके वंशज कठिनाइयों का कारण नहीं बनते हैं। इसलिए, हम समाधान के अधिक जटिल भागों की ओर बढ़ते हैं।

अब हमें basic_data_t के आस-पास एक रैपर की आवश्यकता है, जो कि गेटर तरीके प्रदान करेगा। यह निम्नलिखित फॉर्म का एक टेम्प्लेट क्लास होगा:

 template<typename Basic_Data> class basic_data_holder_t { private : Basic_Data data_; protected : void set_to_extract(int v) { data_.to_extract_ = v; } void set_to_handle(int v) { data_.to_handle_ = v; } void set_common_payload(int v) { data_.common_payload_ = v; } const auto & data() const { return data_; } public : basic_data_holder_t() = default; basic_data_holder_t(Basic_Data data) : data_{std::move(data)} {} int to_extract() const { return data_.to_extract_; } int to_handle() const { return data_.to_handle_; } int common_payload() const { return data_.common_payload_; } }; 

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

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

अब हम कुंजी टेम्प्लेट क्लास पर जा सकते हैं, जो उन लोगों के लिए बहुत डरावना लग सकता है जो आधुनिक C ++ के लिए समर्पित नहीं हैं:

 template<typename Data, typename Derived> class basic_params_t : public basic_data_holder_t<Data> { using base_type = basic_data_holder_t<Data>; public : using actual_type = Derived; using data_type = Data; protected : actual_type & self_reference() { return static_cast<actual_type &>(*this); } decltype(auto) clone_as_defined() { return self_reference().template clone_if_necessary< msg_count_status_t::defined >(); } public : basic_params_t() = default; basic_params_t(data_type data) : base_type{std::move(data)} {} decltype(auto) handle_all() { this->set_to_handle(0); return clone_as_defined(); } decltype(auto) handle_n(int v) { this->set_to_handle(v); return clone_as_defined(); } decltype(auto) extract_n(int v) { this->set_to_extract(v); return clone_as_defined(); } actual_type & common_payload(int v) { this->set_common_payload(v); return self_reference(); } using base_type::common_payload; }; 

यह basic_params_t मुख्य CRTP टेम्प्लेट है। केवल अब इसे दो मापदंडों द्वारा पैरामीटरित किया जाता है।

पहला पैरामीटर डेटा प्रकार है जिसे अंदर होना चाहिए। उदाहरण के लिए, get_specific_data_t या select_specific_data_t।

दूसरा पैरामीटर CRTP के परिचित उत्तराधिकारी का प्रकार है। इसका उपयोग self_reference () पद्धति में एक व्युत्पन्न प्रकार का संदर्भ प्राप्त करने के लिए किया जाता है।

Basic_params_t टेम्पलेट के कार्यान्वयन में महत्वपूर्ण बिंदु इसकी क्लोन_स_डिफाइंड () विधि है। इस विधि से यह उम्मीद है कि वारिस clone_if_n जरूरी () विधि को लागू करेगा। और यह clone_if_n Essential () बस ऑब्जेक्ट T <msg_count_status_t :: undefined> को ऑब्जेक्ट T <msg_count_status_t :: परिभाषित> में बदलने के लिए डिज़ाइन किया गया है। और इस तरह के परिवर्तन को सेटर मेथड्स__ (), हैंडल_ एन () और एक्सट्रैक्ट_ एन () में शुरू किया जाता है।

इसके अलावा, आप इस तथ्य पर ध्यान दे सकते हैं कि clone_as_defined (), handle_all (), handle_n () और extract_n () उनके रिटर्न मूल्य के प्रकार को निर्धारित (ऑटो) के रूप में निर्धारित करते हैं। यह एक और चाल है, जिसके बारे में हम जल्द ही बात करेंगे।

अब हम पहले से ही अंतिम प्रकारों में से एक को देख सकते हैं, जिसके लिए यह सब कल्पना की गई थी:

 template< msg_count_status_t Msg_Count_Status > class receive_specific_params_t final : public basic_params_t< receive_specific_data_t, receive_specific_params_t<Msg_Count_Status> > { using base_type = basic_params_t< receive_specific_data_t, receive_specific_params_t<Msg_Count_Status> >; public : template<msg_count_status_t New_Msg_Count_Status> std::enable_if_t< New_Msg_Count_Status != Msg_Count_Status, receive_specific_params_t<New_Msg_Count_Status> > clone_if_necessary() const { return { this->data() }; } template<msg_count_status_t New_Msg_Count_Status> std::enable_if_t< New_Msg_Count_Status == Msg_Count_Status, receive_specific_params_t& > clone_if_necessary() { return *this; } receive_specific_params_t(int receive_payload) : base_type{ typename base_type::data_type{receive_payload} } {} receive_specific_params_t(typename base_type::data_type data) : base_type{ std::move(data) } {} int receive_payload() const { return this->data().receive_payload_; } }; 

पहली चीज़ जिस पर आपको यहाँ ध्यान देना चाहिए वह है कंस्ट्रक्टर, जो base_type :: data_type लेता है। इस निर्माता का उपयोग करते हुए, वर्तमान पैरामीटर मान T <msg_count_status_t :: undefined> से T <msg_count_status_t :: परिभाषित> में परिवर्तन के दौरान स्थानांतरित किए जाते हैं।

कुछ और बड़े, यह कुछ इस तरह से है:

 template<typename V, int K> class holder_t { V v_; public: holder_t() = default; holder_t(V v) : v_{std::move(v)} {} const V & value() const { return v_; } }; holder_t<std::string, 0> v1{"Hello!"}; holder_t<std::string, 1> v2; v2 = v1; //   ,   v1  v2   . v2 = holder_t<std::string, 1>{v1.value()}; //    . 

और बस उपर्युक्त निर्माणकर्ता get_specific_params_t आपको get_specific_params_t <msg_count_status_t :: define> get_specific_params_t <msg_count_status_t :: undefined> से मानों को आरंभ करने की अनुमति देता है।

Get_specific_params_t में दूसरी महत्वपूर्ण चीज दो क्लोन_निफ़्री (आवश्यक) तरीके हैं।

दो क्यों हैं? और यह सब SFINAE-vskaya जादू का उनकी परिभाषा में क्या मतलब है?

अनावश्यक रूपांतरों से बचने के लिए दो क्लोन_निश्चित (आवश्यक) तरीके बनाए गए हैं। मान लीजिए कि एक प्रोग्रामर को हैंडल_ एन () विधि कहा जाता है और पहले से ही प्राप्त किया गया__ प्राप्त करें_परिनाम_टी <msg_count_status_t :: परिभाषित>। और फिर इसे extract_n () कहा जाता है। यह अनुमत है, handle_n () और extract_n () थोड़ा अलग प्रतिबंध लगाते हैं। Extract_n () के लिए कॉल हमें भी प्राप्त करना चाहिए__प्रतिस्पर्धी_परम_t <msg_count_status_t :: परिभाषित>। लेकिन हमारे पास पहले से ही एक है। तो क्यों नहीं एक मौजूदा एक पुन: उपयोग?

इसीलिए यहां दो क्लोन_निफ़र (आवश्यक) विधियाँ हैं। जब परिवर्तन वास्तव में आवश्यक हो तो पहला काम करेगा:

  template<msg_count_status_t New_Msg_Count_Status> std::enable_if_t< New_Msg_Count_Status != Msg_Count_Status, receive_specific_params_t<New_Msg_Count_Status> > clone_if_necessary() const { return { this->data() }; } 

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

दूसरी विधि:

  template<msg_count_status_t New_Msg_Count_Status> std::enable_if_t< New_Msg_Count_Status == Msg_Count_Status, receive_specific_params_t& > clone_if_necessary() { return *this; } 

तब बुलाया जाएगा जब स्थिति को बदलना आवश्यक न हो। और यह विधि किसी मौजूदा ऑब्जेक्ट का संदर्भ देती है।

अब यह स्पष्ट हो जाना चाहिए कि क्यों कई तरीकों के लिए basic_params_t में वापसी प्रकार को डिक्लेपट (ऑटो) के रूप में परिभाषित किया गया था। आखिरकार, ये विधियाँ इस बात पर निर्भर करती हैं कि क्लोन प्रकार का कौन सा विशेष संस्करण क्लोन किए गए प्रकार में कहा जाएगा, और या तो एक वस्तु या एक लिंक वहां लौटाया जा सकता है ... आप पहले से अनुमान नहीं लगाएंगे। और यहाँ डिक्लेपट (ऑटो) बचाव के लिए आता है।

छोटा खुलासा

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

उदाहरण के लिए, basic_data_holder_t :: data () विधि डेटा के लिए एक निरंतर संदर्भ देता है। यह T <msg_count_status_t :: undefined> से T <msg_count_status_t :: परिभाषित> के रूपांतरण के दौरान पैरामीटर मानों की प्रतिलिपि बनाता है। यदि मापदंडों की नकल करना एक महंगा ऑपरेशन है, तो आपको कदम शब्दार्थ से हैरान होना चाहिए और डेटा () विधि निम्नलिखित हो सकती है:

 auto data() { return std::move(data_); } 

अब भी, हर अंतिम प्रकार में (जैसे get_specific_params_t और select_specific_params_t), आपको क्लोन-लागू_ आवश्यक तरीकों के कार्यान्वयन को शामिल करना होगा। यानी इस जगह में हम अभी भी कॉपी पेस्ट का उपयोग करते हैं। शायद एक ही प्रकार के कोड के दोहराव से बचने के लिए भी कुछ होना चाहिए।

"सिंटैक्स ओवरहेड" (ओं) को कम करने के लिए कोड में नीचे और अच्छी तरह से हाँ, noexcept नहीं रखा गया है।

वह सब

यहां चर्चा की गई न्यूनतर उदाहरण के लिए स्रोत कोड यहां पाया जा सकता है । और आप ऑन-लाइन संकलक में खेल सकते हैं, उदाहरण के लिए, यहां (आप लाइन 163 पर हैंडल_all () पर कॉल को देख सकते हैं और देखें कि क्या होता है)।

मैं यह नहीं कहना चाहता हूं कि मैंने जो दृष्टिकोण लागू किया है वह एकमात्र सही है। लेकिन, सबसे पहले, मैंने कॉपी-पेस्ट में एक विकल्प देखा। और, दूसरी बात, ऐसा करना बिल्कुल भी मुश्किल नहीं था, और सौभाग्य से, इसमें बहुत समय नहीं लगा। लेकिन कंपाइलर के घूंसे ने तुरंत मदद की, क्योंकि पुराने परीक्षणों और उदाहरणों ने सोबिजाइज़र के नवीनतम संस्करण की नई विशेषताओं के अनुकूल किया।

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

पुनश्च। यदि पाठकों में से एक SObjectizer का अनुसरण करता है, तो मैं कह सकता हूं कि नया संस्करण 5.6, जिसमें 5.5 शाखा के साथ संगतता का काफी उल्लंघन किया गया था, पहले से ही काफी सांस ले रहा था। आप इसे BitBucket पर पा सकते हैं। रिलीज़ अभी भी एक लंबा रास्ता तय कर रहा है, लेकिन SObjectizer-5.6 पहले से ही है जो इसका मतलब था। आप अपने इंप्रेशन को ले, आज़मा सकते हैं और साझा कर सकते हैं।