Restinio एक अपेक्षाकृत छोटी परियोजना है, जो C ++ अनुप्रयोगों में निर्मित एक अतुल्यकालिक HTTP सर्वर है। इसकी विशेषता विशेषता व्यापक है, कोई कह सकता है कि, C ++ टेम्पलेट्स का व्यापक उपयोग। कार्यान्वयन और सार्वजनिक एपीआई दोनों में।

RESTinio में C ++ टेम्प्लेट इतनी सक्रियता से उपयोग किए जाते हैं कि हेबर पर Restinio के बारे में बात करने वाले पहले लेख को " मानव चेहरे के साथ एम्बेडेड अतुल्यकालिक HTTP सर्वर के कार्यान्वयन में तीन-कहानी C ++ टेम्पलेट " कहा गया था।

तीन-कहानी टेम्पलेट। और यह, सामान्य रूप से, भाषण का एक आंकड़ा नहीं था।

और हाल ही में, हमने एक बार फिर से रेस्टीनियो को अपडेट किया, और संस्करण 0.5.1 में नई कार्यक्षमता जोड़ने के लिए, हमें टेम्प्लेट की "संख्याओं" को और भी अधिक करना पड़ा। तो स्थानों में C ++ टेम्पलेट्स RESTinio में पहले से ही चार-कहानी है।

और अगर कोई सोच रहा है कि हमें इसकी आवश्यकता क्यों है और हमने टेम्पलेट्स का उपयोग कैसे किया, तो हमारे साथ रहें, कट के तहत कुछ विवरण होंगे। Inveterate C ++ गुरुओं को अपने लिए कुछ भी नया पाने की संभावना नहीं है, लेकिन कम उन्नत C ++ उपनाम यह देखने में सक्षम होंगे कि कार्यक्षमता के टुकड़े सम्मिलित करने / निकालने के लिए टेम्पलेट का उपयोग कैसे किया जाता है। लगभग जंगली में।

कनेक्शन स्थिति श्रोता

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

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

और चूंकि Restinio में HTTP सर्वर की मुख्य विशेषताओं को "लक्षण" के माध्यम से सेट किया गया है, इसलिए सर्वर गुणों के माध्यम से कनेक्शन की स्थिति पर सुनने को सक्षम / अक्षम करने का निर्णय लिया गया था।

एक उपयोगकर्ता कनेक्शन की स्थिति के लिए अपने स्वयं के श्रोता को कैसे सेट करता है?

कनेक्शन की स्थिति के लिए अपने श्रोता को सेट करने के लिए , उपयोगकर्ता को तीन चरण करने होंगे।

चरण # 1: अपने स्वयं के वर्ग को परिभाषित करें, जिसमें निम्नलिखित रूप से गैर-स्थिर स्थिति में परिवर्तन करना चाहिए:

void state_changed( const restinio::connection_state::notice_t & notice) noexcept; 

उदाहरण के लिए, यह कुछ इस तरह हो सकता है:

 class my_state_listener { std::mutex lock_; ... public: void state_changed(const restinio::connection_state::notice_t & notice) noexcept { std::lock_guard<std::mutex> l{lock_}; .... } ... }; 

चरण # 2: सर्वर के गुणों के अंदर, आपको एक टाइपडिफ को परिभाषित करना होगा, जिसे कनेक्शन_स्टैट_लिस्टनर_ट कहा जाता connection_state_listener_t , जिसे चरण # 1 में बनाए गए प्रकार के नाम का उल्लेख करना चाहिए:

 struct my_traits : public restinio::default_traits_t { using connection_state_listener_t = my_state_listener; }; 

तदनुसार, HTTP सर्वर शुरू करते समय इन गुणों का उपयोग किया जाना चाहिए:

 restinio::run(restinio::on_thread_pool<my_traits>(8)...); 

चरण # 3: उपयोगकर्ता को अपने श्रोता का एक उदाहरण बनाना होगा और सर्वर पैरामीटर में शेयर्ड_प्ट्र के माध्यम से इस सूचक को पास करना होगा:

 restinio::run( restinio::on_thread_pool<my_traits>(8) .port(8080) .address("localhost") .request_handler(...) .connection_state_listener(std::make_shared<my_state_listener>(...)) ) ); 

यदि उपयोगकर्ता connection_state_listener विधि को कॉल नहीं करता है, तो HTTP सर्वर शुरू करते समय एक अपवाद को फेंक दिया जाएगा: उत्तर काम नहीं कर सकता है यदि उपयोगकर्ता राज्य श्रोता का उपयोग करना चाहता है, लेकिन इस श्रोता को निर्दिष्ट नहीं किया है।

और अगर आप कनेक्शन_स्टैट_लिस्टर_t सेट नहीं करते हैं?

यदि उपयोगकर्ता सर्वर गुणों में connection_state_listener_t नाम सेट करता है, तो उसे सर्वर पैरामीटर सेट करने के लिए connection_state_listener विधि को कॉल करना होगा। लेकिन अगर उपयोगकर्ता connection_state_listener_t निर्दिष्ट नहीं करता है?

इस स्थिति में, connection_state_listener_t नाम अभी भी सर्वर गुणों में मौजूद होगा, लेकिन यह नाम विशेष प्रकार के restinio::connection_state::noop_listener_t को इंगित करेगा restinio::connection_state::noop_listener_t ।

वास्तव में, निम्न होता है: Restinio में, जब नियमित लक्षण निर्धारित करते हैं, तो मान कनेक्शन_state_listener_t सेट होता है। कुछ इस तरह:

 namespace restinio { struct default_traits_t { using time_manager_t = asio_time_manager_t; using logger_t = null_logger_t; ... using connection_state_listener_t = connection_state::noop_listener_t; }; } /* namespace restinio */ 

और जब उपयोगकर्ता को restinio::default_traits_t से विरासत में मिला है, तो connection_state_listener_t की मानक परिभाषा भी विरासत में मिली है। लेकिन यदि उत्तराधिकारी वर्ग में नया नाम connection_state_listener_t परिभाषित किया गया है:

 struct my_traits : public restinio::default_traits_t { using connection_state_listener_t = my_state_listener; ... }; 

फिर नया नाम कनेक्शन_स्टैट_लिस्टनर_ टी के लिए विरासत में मिली परिभाषा को छुपाता है। और अगर कोई नई परिभाषा नहीं है, तो पुरानी परिभाषा दिखाई देती है।

इसलिए यदि उपयोगकर्ता कनेक्शन_स्टैट_लिस्टर_ के लिए अपने स्वयं के मूल्य को परिभाषित नहीं करता है, तो RESTINIO डिफ़ॉल्ट मान, noop_listener_t उपयोग करेगा, जिसे Restinio द्वारा एक विशेष तरीके से संसाधित किया जाता है। उदाहरण के लिए:

• RESTINIO इस मामले में connection_state_listener_t लिए साझा नहीं करता है। और, तदनुसार, connection_state_listener पद्धति के लिए एक कॉल निषिद्ध है (इस तरह के कॉल से संकलन-समय त्रुटि हो जाएगी);
• Restinio कनेक्शन की स्थिति को बदलने से संबंधित कोई अतिरिक्त कॉल नहीं करता है।

और बस यह कैसे हासिल किया जाता है और नीचे चर्चा की जाएगी।

यह RESTINIO में कैसे लागू किया गया है?

तो, RESTINIO कोड में, आपको यह जांचने की आवश्यकता है कि सर्वर के गुणों में connection_state_listener_t की परिभाषा क्या है और इस मूल्य के आधार पर:

• किसी ऑब्जेक्ट के प्रकार connecton_state_listener_t लिए साझा करने के लिए या संग्रहीत करने के लिए नहीं;
• HTTP सर्वर पैरामीटर सेट करने के लिए connection_state_listener विधियों पर कॉल करने की अनुमति दें या रोकें;
• HTTP सर्वर के संचालन को शुरू करने से पहले एक प्रकार की सूचक की उपस्थिति के लिए जाँच करें या नहीं connection_state_listener_t type_state_listener_t की वस्तु के लिए;
• क्लाइंट के कनेक्शन की स्थिति में परिवर्तन होने पर state_changed तरीके से कॉल करें या न करें।

यह सीमा की स्थितियों में भी जोड़ा जाता है कि Restinio अभी भी C ++ 14 के लिए एक पुस्तकालय के रूप में विकसित हो रहा है, इसलिए, आप कार्यान्वयन में C ++ 17 की क्षमताओं का उपयोग नहीं कर सकते हैं (यदि कॉन्स्ट्रेप वही)।

यह सब साधारण ट्रिक्स के माध्यम से लागू किया गया है: restinio::connection_state::noop_listener_t कक्षाएं और restinio::connection_state::noop_listener_t टाइप के लिए उनकी विशेषज्ञता restinio::connection_state::noop_listener_t । उदाहरण के लिए, यहां बताया गया है कि किस प्रकार सर्वर के मापदंडों में type कनेक्शन_state_listener_t के लिए साझा किया गया। भाग एक:

 template< typename Listener > struct connection_state_listener_holder_t { ... //  compile-time . std::shared_ptr< Listener > m_connection_state_listener; static constexpr bool has_actual_connection_state_listener = true; void check_valid_connection_state_listener_pointer() const { if( !m_connection_state_listener ) throw exception_t{ "connection state listener is not specified" }; } }; template<> struct connection_state_listener_holder_t< connection_state::noop_listener_t > { static constexpr bool has_actual_connection_state_listener = false; void check_valid_connection_state_listener_pointer() const { // Nothing to do. } }; 

एक टेम्पलेट संरचना यहां परिभाषित की गई है कि या तो एक उपयोगी सामग्री है या नहीं। बस noop_listener_t प्रकार के लिए, इसमें कोई उपयोगी सामग्री नहीं है।

और भाग दो:

 template<typename Derived, typename Traits> class basic_server_settings_t : public socket_type_dependent_settings_t< Derived, typename Traits::stream_socket_t > , protected connection_state_listener_holder_t< typename Traits::connection_state_listener_t > , protected ip_blocker_holder_t< typename Traits::ip_blocker_t > { ... }; 

HTTP सर्वर के लिए पैरामीटर वाले वर्ग को कनेक्शन_state_listener_holder_t से विरासत में मिला है। इस प्रकार, सर्वर पैरामीटर या तो type_state_listener_t प्रकार की वस्तु के लिए साझा करें, या यह प्रदर्शित नहीं करता है।

मुझे कहना होगा कि मापदंडों में साझा किए गए भंडार को संग्रहीत करना या न करना फूल हैं। लेकिन बेरीज़ तब गए जब noop_listener_t में राज्य श्रोता के साथ काम करने के लिए इच्छित तरीकों को उपलब्ध कराने का प्रयास किया गया, यदि केवल noop_listener_t , noop_listener_t से noop_listener_t ।

आदर्श रूप से, मैं कंपाइलर को "उन्हें नहीं देखना" बनाना चाहता था। लेकिन मुझे इन तरीकों को छिपाने के लिए std::enable_if लिए शर्तों को लिखने के लिए यातना दी गई थी। इसलिए, यह static_asser जोड़ने के लिए सीमित था:

 Derived & connection_state_listener( std::shared_ptr< typename Traits::connection_state_listener_t > listener ) & { static_assert( has_actual_connection_state_listener, "connection_state_listener(listener) can't be used " "for the default connection_state::noop_listener_t" ); this->m_connection_state_listener = std::move(listener); return reference_to_derived(); } Derived && connection_state_listener( std::shared_ptr< typename Traits::connection_state_listener_t > listener ) && { return std::move(this->connection_state_listener(std::move(listener))); } const std::shared_ptr< typename Traits::connection_state_listener_t > & connection_state_listener() const noexcept { static_assert( has_actual_connection_state_listener, "connection_state_listener() can't be used " "for the default connection_state::noop_listener_t" ); return this->m_connection_state_listener; } void ensure_valid_connection_state_listener() { this->check_valid_connection_state_listener_pointer(); } 

एक और क्षण था जब मुझे पछतावा हुआ कि सी ++ में अगर कॉन्स्ट्रेक्स स्थिर नहीं है यदि डी। और C ++ 14 में सामान्य रूप से समान नहीं है :(

यहां आप ensure_valid_connection_state_listener पद्धति की उपलब्धता भी देख सकते हैं। सर्वर पैरामीटर सभी आवश्यक मानों को सत्यापित करने के लिए इस विधि को http_server_t कंस्ट्रक्टर में कहा जाता है:

 template<typename D> http_server_t( io_context_holder_t io_context, basic_server_settings_t< D, Traits > && settings ) : m_io_context{ io_context.giveaway_context() } , m_cleanup_functor{ settings.giveaway_cleanup_func() } { // Since v.0.5.1 the presence of custom connection state // listener should be checked before the start of HTTP server. settings.ensure_valid_connection_state_listener(); ... 

एक ही समय में, ensure_valid_connection_state_listener लिए check_valid_connection_state_listener_pointer , जिसे ensure_valid_connection_state_listener विशेषज्ञता प्राप्त है, या तो वास्तविक चेक नहीं है।

यदि उपयोगकर्ता राज्य श्रोता का उपयोग करना चाहते हैं, या अन्यथा कुछ भी नहीं कहते हैं तो इसी तरह की चाल का उपयोग वर्तमान स्थिति को state_changed लिए किया जाता था।

सबसे पहले, हमें एक और state_listener_holder_t विकल्प की आवश्यकता है:

 namespace connection_settings_details { template< typename Listener > struct state_listener_holder_t { std::shared_ptr< Listener > m_connection_state_listener; template< typename Settings > state_listener_holder_t( const Settings & settings ) : m_connection_state_listener{ settings.connection_state_listener() } {} template< typename Lambda > void call_state_listener( Lambda && lambda ) const noexcept { m_connection_state_listener->state_changed( lambda() ); } }; template<> struct state_listener_holder_t< connection_state::noop_listener_t > { template< typename Settings > state_listener_holder_t( const Settings & ) { /* nothing to do */ } template< typename Lambda > void call_state_listener( Lambda && /*lambda*/ ) const noexcept { /* nothing to do */ } }; } /* namespace connection_settings_details */ 

कनेक्शन_स्टैट_लिस्टर_होल्डर_ट के विपरीत, जो पहले दिखाया गया था और जिसका उपयोग पूरे सर्वर के मापदंडों में कनेक्शन की स्थिति श्रोता को संग्रहित करने के लिए किया गया था (यानी, प्रकार के ऑब्जेक्ट्स में basic_server_settings_t ), यह state_listener_holder_t समान उद्देश्यों के लिए उपयोग किया जाएगा, लेकिन पूरे सर्वर के मापदंडों में नहीं। कनेक्टिविटी:

 template < typename Traits > struct connection_settings_t final : public std::enable_shared_from_this< connection_settings_t< Traits > > , public connection_settings_details::state_listener_holder_t< typename Traits::connection_state_listener_t > { using connection_state_listener_holder_t = connection_settings_details::state_listener_holder_t< typename Traits::connection_state_listener_t >; ... 

यहां दो विशेषताएं हैं।

सबसे पहले, state_listener_holder_t प्रारंभ state_listener_holder_t । इसकी जरूरत है भी या नहीं। लेकिन केवल state_listener_holder_t इसके बारे में जानता है। इसलिए, state_listener_holder_t कंस्ट्रक्टर बस state_listener_holder_t कंस्ट्रक्टर को "खींचता है", जैसा कि वे कहते हैं, बस मामले में:

 template < typename Settings > connection_settings_t( Settings && settings, http_parser_settings parser_settings, timer_manager_handle_t timer_manager ) : connection_state_listener_holder_t{ settings } , m_request_handler{ settings.request_handler() } 

और state_listener_holder_t कंस्ट्रक्टर state_listener_holder_t या तो आवश्यक कार्रवाई करता है या कुछ भी नहीं करता है (बाद वाले मामले में, अधिक या कम समझदार कंपाइलर state_listener_holder_t को शुरू करने के लिए कोई कोड उत्पन्न नहीं करेगा)।

दूसरे, यह state_listner_holder_t::call_state_listener , जो राज्य श्रोता को राज्य- state_changed कॉल करता है। या नहीं, अगर कोई राज्य श्रोता नहीं है। यह call_state_listener स्थानों पर call_state_listener है जहां रेस्टिनियो कनेक्शन स्थिति में परिवर्तन का निदान करता है। उदाहरण के लिए, जब यह पता चलता है कि कनेक्शन बंद कर दिया गया है:

 void close() { m_logger.trace( [&]{ return fmt::format( "[connection:{}] close", connection_id() ); } ); ... // Inform state listener if it used. m_settings->call_state_listener( [this]() noexcept { return connection_state::notice_t{ this->connection_id(), this->m_remote_endpoint, connection_state::cause_t::closed }; } ); } 

एक call_state_listener को call_state_listener पास किया call_state_listener , जहाँ से कनेक्शन की स्थिति की जानकारी के साथ एक notice_t वस्तु वापस की जाती है। यदि कोई वास्तविक श्रोता है, तो यह state_changed वास्तव में कहा जाएगा, और इसके द्वारा लौटाया गया मूल्य state_changed को दिया जाएगा।

हालाँकि, यदि कोई श्रोता नहीं है, तो call_state_listener खाली हो जाएगा और, तदनुसार, कोई call_state_listener नहीं कहा जाएगा। वास्तव में, सामान्य कंपाइलर सभी कॉल को एक खाली call_state_listener । और इस मामले में, उत्पन्न कोड में श्रोता द्वारा एक्सेस की जा रही कनेक्शन स्थिति से संबंधित कुछ भी नहीं होगा।

इसके अलावा आईपी अवरोधक

Restinio-0.5.1 में, कनेक्शन स्थिति श्रोता के अलावा, IP- अवरोधक के रूप में ऐसी चीज जोड़ी गई थी। यानी उपयोगकर्ता एक ऑब्जेक्ट निर्दिष्ट कर सकता है जो RESTinio प्रत्येक नए आने वाले कनेक्शन के लिए "खींच" करेगा। यदि आईपी-अवरोधक कहता है कि आप कनेक्शन के साथ काम कर सकते हैं, तो Restinio नए कनेक्शन का सामान्य रखरखाव शुरू करता है (यह अनुरोध पढ़ता है और पार्स करता है, अनुरोध-हैंडलर को कॉल करता है, टाइमआउट को नियंत्रित करता है, आदि)। लेकिन अगर आईपी-अवरोधक कनेक्शन के साथ काम करने पर प्रतिबंध लगाता है, तो Restinio मूर्खता से इस कनेक्शन को बंद कर देता है और इसके साथ अधिक कुछ नहीं करता है।

राज्य श्रोता की तरह, आईपी-ब्लॉकर एक वैकल्पिक विशेषता है। IP अवरोधक का उपयोग करने के लिए, आपको इसे स्पष्ट रूप से सक्षम करना होगा। HTTP सर्वर के गुणों के माध्यम से। कनेक्शन स्थिति श्रोता की तरह। और Restinio में IP अवरोधक समर्थन के कार्यान्वयन में उन्हीं तकनीकों का उपयोग किया गया है जो पहले ही ऊपर वर्णित की जा चुकी हैं। इसलिए, हम यह नहीं बताएंगे कि Restinio के अंदर IP-blocker का उपयोग कैसे किया जाता है। इसके बजाय, एक उदाहरण पर विचार करें जिसमें आईपी अवरोधक और राज्य श्रोता दोनों एक ही वस्तु हैं।

मानक उदाहरण ip_blocker का विश्लेषण

संस्करण 0.5.1 में, एक और उदाहरण मानक रेस्टिनियो उदाहरणों में शामिल है: ip_blocker । यह उदाहरण दर्शाता है कि आप एकल आईपी पते से सर्वर से समवर्ती कनेक्शन की संख्या को कैसे सीमित कर सकते हैं।

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

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

कोई बात नहीं, हम आसानी से यह कर सकते हैं:

 class blocker_t { std::mutex m_lock; using connections_t = std::map< restinio::asio_ns::ip::address, std::vector< restinio::connection_id_t > >; connections_t m_connections; public: //   IP-blocker-. restinio::ip_blocker::inspection_result_t inspect( const restinio::ip_blocker::incoming_info_t & info ) noexcept {...} //     . void state_changed( const restinio::connection_state::notice_t & notice ) noexcept {...} }; 

यहां हमें विरासत में मिली आभासी विधियों के किसी भी इंटरफेस या ओवरराइड से कोई विरासत नहीं मिली है। श्रोता के लिए एकमात्र आवश्यकता राज्य की स्थिति की उपस्थिति है। यह आवश्यकता संतुष्ट है।

इसी तरह, एक आईपी अवरोधक के लिए केवल आवश्यकता के साथ: क्या आवश्यक हस्ताक्षर के साथ एक inspect विधि है? वहाँ है! तो सब ठीक है।

तब यह HTTP सर्वर के लिए सही गुण निर्धारित करने के लिए रहता है:

 struct my_traits_t : public restinio::default_traits_t { using logger_t = restinio::shared_ostream_logger_t; //      . using connection_state_listener_t = blocker_t; using ip_blocker_t = blocker_t; }; 

उसके बाद, यह केवल blocker_t का एक उदाहरण बनाने और इसे HTTP सर्वर में मापदंडों में पारित करने के लिए बना हुआ है:

 auto blocker = std::make_shared<blocker_t>(); restinio::run( ioctx, restinio::on_thread_pool<my_traits_t>( std::thread::hardware_concurrency() ) .port( 8080 ) .address( "localhost" ) .connection_state_listener( blocker ) .ip_blocker( blocker ) .max_pipelined_requests( 4 ) .handle_request_timeout( std::chrono::seconds{20} ) .request_handler( [&ioctx](auto req) { return handler( ioctx, std::move(req) ); } ) ); 

निष्कर्ष

C ++ टेम्प्लेट के बारे में

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

उनमें से एक के प्रतिनिधि टेम्पलेट्स से दूर रहना पसंद करते हैं। क्योंकि टेम्प्लेट जटिल हैं, वे त्रुटि संदेशों की अपठनीय चादरों की अपठनीय लंबाई उत्पन्न करते हैं, संकलन समय में काफी वृद्धि करते हैं। ब्लोटिंग कोड और प्रदर्शन को कम करने के बारे में शहरी किंवदंतियों का उल्लेख नहीं करना।

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

इसलिए, यह मुझे व्यक्तिगत रूप से लगता है कि Restinio के कार्यान्वयन के दौरान चुने गए दृष्टिकोण, अर्थात् टेम्पलेट्स का व्यापक उपयोग और गुणों के माध्यम से एक HTTP सर्वर की विशेषताओं को निर्दिष्ट करना, अभी भी भुगतान करता है। इसके लिए धन्यवाद, हमें विशिष्ट आवश्यकताओं के लिए अच्छा अनुकूलन मिलता है। और एक ही समय में, शाब्दिक अर्थों में, हम उस चीज के लिए भुगतान नहीं करते हैं जो हम उपयोग नहीं करते हैं।

हालांकि, दूसरी ओर, ऐसा लगता है कि C ++ टेम्प्लेट में प्रोग्रामिंग अभी भी अनुचित रूप से जटिल है। आप इसे विशेष रूप से महसूस करते हैं जब आपको लगातार नहीं बल्कि विभिन्न गतिविधियों के बीच स्विच करना होता है। आपको कोडिंग से कुछ हफ़्ते के लिए विचलित कर दिया जाएगा, फिर आप वापस लौटेंगे और खुलकर शुरू करेंगे और विशेष रूप से बेवकूफ होंगे यदि आवश्यक हो, तो SFINAE का उपयोग करके किसी विधि को छिपाएं या जांचें कि ऑब्जेक्ट पर एक निश्चित हस्ताक्षर के साथ एक विधि है या नहीं।

इसलिए यह अच्छा है कि C ++ में टेम्प्लेट हैं। यह और भी बेहतर होगा यदि उन्हें ऐसी अवस्था में लाया जाए कि मेरे जैसे शुरुआत करने वाले भी हर 10-15 मिनट में cppreference और stackoverflow का अध्ययन किए बिना आसानी से C ++ टेम्पलेट का उपयोग कर सकें।

RESTINIO की वर्तमान स्थिति और RESTINIO की भावी कार्यक्षमता के बारे में। और केवल Restinio ही नहीं

फिलहाल, रेस्टिनियो "जब समय होता है और एक विशलिस्ट होता है" के सिद्धांत पर विकसित हो रहा है। उदाहरण के लिए, 2018 के पतन और 2019 की सर्दियों में, हमारे पास Restinio के विकास के लिए ज्यादा समय नहीं था। उन्होंने उपयोगकर्ताओं के सवालों के जवाब दिए, मामूली बदलाव किए, लेकिन कुछ अधिक के लिए हमारे संसाधन पर्याप्त नहीं थे।

लेकिन 2019 के उत्तरार्ध में, Restinio के लिए समय था, और हमने पहले Restinio 0.5.0 , और फिर 0.5.1 बनाया । उसी समय, हमारी और दूसरों की विशलिस्ट की आपूर्ति समाप्त हो गई थी। यानी हम खुद RESTINIO में क्या देखना चाहते थे और उपयोगकर्ताओं ने हमें किस बारे में बताया, यह RESTinio में पहले से है।

जाहिर है, रेस्टिनियो को बहुत अधिक भरा जा सकता है। लेकिन वास्तव में क्या?

और यहाँ उत्तर बहुत सरल है: केवल वही जो हमें Restinio में लाने के लिए कहा जाता है। इसलिए, यदि आप Restinio में अपनी ज़रूरत की कोई चीज़ देखना चाहते हैं, तो समय निकालकर हमें इसके बारे में बताएं (उदाहरण के लिए, GitHub या BitBucket पर मुद्दों के माध्यम से, या तो Google समूह के माध्यम से, या सीधे यहाँ टिप्पणियों में) । आप कुछ नहीं कहेंगे - आपको कुछ भी प्राप्त नहीं होगा;)

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

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