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

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

उदाहरण के लिए, यदि मेरे पास ये प्रकार और कार्य हैं:

class first_resource {...}; class second_resource {...}; void release(first_resource & r) noexcept; void close(second_resource & r); 

और एक निश्चित first_resource क्लास है जो first_resource और first_resource जैसी वस्तुओं का मालिक है:

 class resources_owner { first_resource first_resource_; second_resource second_resource_; ... }; 

उसके बाद मैं resources_owner डिस्ट्रक्टर को इस प्रकार लिख सकता हूँ:

 resources_owner::~resources_owner() noexcept { //  release()   ,    . release(first_resource_); //    close()   ,  //   try-catch. try{ close(second_resource_); } catch(...) {} } 

एक तरह से, C ++ 11 में noexcept ने C ++ डेवलपर के जीवन को आसान बना दिया। लेकिन आधुनिक C ++ में वर्तमान नॉइसेसेप्ट कार्यान्वयन एक बुरा पक्ष है ...

कंपाइलर noexcept फ़ंक्शन और विधियों की सामग्री को नियंत्रित करने में मदद नहीं करता है

मान लीजिए कि उपरोक्त उदाहरण में मुझसे गलती हुई थी: किसी कारण से, मैंने release() noexcept के रूप में चिह्नित release() माना, लेकिन वास्तव में यह अपवाद नहीं है और इसे फेंक सकता है। इसका मतलब यह है कि जब मैं ऐसी फेंकने वाली release() का उपयोग करके एक विध्वंसक लिखता हूं:

 resources_owner::~resources_owner() noexcept { release(first_resource_); //  try-catch   ... } 

तब मैं भीख मांगता हूं। जल्दी या बाद में, यह release() एक अपवाद को फेंक देगा और मेरा पूरा एप्लिकेशन स्वचालित रूप से std::terminate() कारण क्रैश हो जाएगा। यह और भी बुरा होगा यदि मेरा एप्लिकेशन क्रैश नहीं होता है, लेकिन किसी और का, जिसमें उन्होंने मेरे पुस्तकालय का उपयोग resources_owner लिए ऐसे समस्याग्रस्त विध्वंसक के साथ किया।

या उसी समस्या का एक और रूपांतर। मान लीजिए कि मुझसे गलती नहीं हुई कि release() वास्तव में noexcept के रूप में चिह्नित है। यह था

इसे तीसरे पक्ष के पुस्तकालय के संस्करण 1.0 में टैग किया गया था जिसमें से मैंने first_resource और release() । और फिर, कई वर्षों के बाद, मैंने इस लाइब्रेरी के संस्करण 3.0 में अपग्रेड किया, लेकिन संस्करण 3.0 release() अब एक noexcept संशोधक नहीं है।

खैर, क्या? नया प्रमुख संस्करण, वे आसानी से एपीआई तोड़ सकते हैं।

केवल अब, सबसे अधिक संभावना है, मैं resources_owner विध्वंसक के कार्यान्वयन को ठीक करना भूल जाऊंगा। और अगर मेरे बजाय कोई और व्यक्ति रिसोर्स_ओनर के समर्थन में लगा हुआ है, जिसने इस विध्वंसक पर कभी गौर नहीं किया, तो release() हस्ताक्षर में बदलाव शायद किसी का ध्यान नहीं जाएगा।

इसलिए, मैं व्यक्तिगत रूप से इस तथ्य को पसंद नहीं करता हूं कि कंपाइलर प्रोग्रामर को किसी भी तरह से चेतावनी नहीं देता है कि नोसेप्ट विधि / फ़ंक्शन के अंदर प्रोग्रामर अपवाद-फेंकने की विधि / फ़ंक्शन कॉल करता है।

बेहतर होगा कि कंपाइलर इस तरह की चेतावनी जारी करे।

डूबने से बचाव खुद डूबने का काम है

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

क्या इसकी चपेट में आए बिना कंपाइलर की मदद लेना संभव है? यानी क्या नोइसेप्ट तरीकों / कार्यों की सामग्री को नियंत्रित करने के लिए कुछ प्रकार के उपकरण बनाना संभव है, भले ही डेंड्रो-फेकल विधि?

आप कर सकते हैं। मैला, लेकिन संभव है।

पैर कहाँ से बढ़ते हैं?

इस आलेख में वर्णित दृष्टिकोण को हमारे छोटे एम्बेडेड एचटीटीपी सर्वर रेस्टिनियो के अगले संस्करण की तैयारी करते समय अभ्यास में परीक्षण किया गया था।

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

सौभाग्य से, व्यवहार में, इन समस्याओं को कभी भी प्रकट नहीं किया गया है, लेकिन तकनीकी ऋण जमा हुआ है और इसके बारे में कुछ किया जाना था। और आपको कोड के साथ कुछ करना था जो पहले से ही लिखा गया था। यानी काम कर रहे गैर- noexcept कोड को noexcept कोड में परिवर्तित किया जाना चाहिए।

यह कई मैक्रोज़ की मदद से किया गया था, जिन्हें सही स्थानों पर कोड द्वारा व्यवस्थित किया गया था। उदाहरण के लिए, एक तुच्छ मामला:

 template< typename Message_Builder > void trigger_error_and_close( Message_Builder msg_builder ) noexcept { // An exception from logger/msg_builder shouldn't prevent // a call to close(). restinio::utils::log_error_noexcept( m_logger, std::move(msg_builder) ); RESTINIO_ENSURE_NOEXCEPT_CALL( close() ); } 

और यहाँ एक तुच्छ टुकड़ा है:

 void reset() noexcept { RESTINIO_STATIC_ASSERT_NOEXCEPT(m_context_table.empty()); RESTINIO_STATIC_ASSERT_NOEXCEPT( m_context_table.pop_response_context_nonchecked()); RESTINIO_STATIC_ASSERT_NOEXCEPT(m_context_table.front()); RESTINIO_STATIC_ASSERT_NOEXCEPT(m_context_table.front().dequeue_group()); RESTINIO_STATIC_ASSERT_NOEXCEPT(make_asio_compaible_error( asio_convertible_error_t::write_was_not_executed)); for(; !m_context_table.empty(); m_context_table.pop_response_context_nonchecked() ) { const auto ec = make_asio_compaible_error( asio_convertible_error_t::write_was_not_executed ); auto & current_ctx = m_context_table.front(); while( !current_ctx.empty() ) { auto wg = current_ctx.dequeue_group(); restinio::utils::suppress_exceptions_quietly( [&] { wg.invoke_after_write_notificator_if_exists( ec ); } ); } } } 

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

तो नीचे वर्णित दृष्टिकोण, निश्चित रूप से, एक स्व-निर्मित वर्ग पहियों के साथ लिसोपेड है, लेकिन यह जाता है ... मेरा मतलब है कि यह काम करता है।

लेख में आगे, हम कार्यान्वयन के बारे में चर्चा करेंगे जो रैस्टिनियो कोड से मैक्रोज़ के एक अलग सेट में अलग किया गया था।

दृष्टिकोण का सार

दृष्टिकोण का सार कथन / ऑपरेटर (stmt) को पास करना है, जिसे एक निश्चित मैक्रो में, noexcept के लिए जाँचने की आवश्यकता है। यह मैक्रो static_assert(noexcept(stmt), msg) का उपयोग करके यह प्रमाणित करता है कि sttt वास्तव में noexcept है, और फिर कोड में stmt को प्रतिस्थापित करता है।

अनिवार्य रूप से, यह है:

 ENSURE_NOEXCEPT_STATEMENT(release(some_resource)); 

कुछ इस तरह से प्रतिस्थापित किया जाएगा:

 static_assert(noexcept(release(some_resource)), "release(some_resource) is expected to be noexcept"); release(some_resource); 

मैक्रों के पक्ष में चुनाव क्यों किया गया?

सिद्धांत रूप में, कोई भी मैक्रोज़ के बिना कर सकता था और कोई भी कार्रवाई किए जाने से ठीक पहले कोड में static_assert(noexcept(...)) लिख सकता था। लेकिन मैक्रोज़ में कम से कम कुछ गुण होते हैं जो विशेष रूप से मैक्रोज़ का उपयोग करने के पक्ष में तराजू को टिप देते हैं।

सबसे पहले, मैक्रोज़ कोड दोहराव को कम करते हैं। एक तुलना है:

 static_assert(noexcept(release(some_resource)), "release(some_resource) is expected to be noexcept"); release(some_resource); 

और

 ENSURE_NOEXCEPT_STATEMENT(release(some_resource)); 

यह स्पष्ट है कि मैक्रोज़ मुख्य अभिव्यक्ति के साथ, अर्थात्। release(some_resource) केवल एक बार लिखा जा सकता है। यह समय के साथ कोड "रेंगने" की संभावना को कम कर देता है, इसकी संगत के साथ, जब एक स्थान पर एक सुधार किया गया था और दूसरे में भूल गया था।

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

तो मैक्रोज़, हालांकि वे C ++ में एक पुरानी और अत्यधिक विवादास्पद विशेषता हैं, इस विशेष मामले में, डेवलपर का जीवन सरल है।

मुख्य मैक्रो ENSURE_NOEXCEPT_STATEMENT

मुख्य मैक्रो ENSURE_NOEXCEPT_STATEMENT को तुच्छ रूप से लागू किया गया है:

 #define ENSURE_NOEXCEPT_STATEMENT(stmt) \ do { \ static_assert(noexcept(stmt), "this statement is expected to be noexcept: " #stmt); \ stmt; \ } while(false) 

यह सत्यापित करने के लिए उपयोग किया जाता है कि कॉल की गई विधियाँ / फ़ंक्शन वास्तव में noexcept हैं और उनके कॉल को try-catch ब्लॉक्स द्वारा फ़्रेम किए जाने की आवश्यकता नहीं है। उदाहरण के लिए:

 class some_complex_container { one_container first_data_part_; another_container second_data_part_; ... public: friend void swap(some_complex_container & a, some_complex_container & b) noexcept { using std::swap; //  swap  noexcept,    . ENSURE_NOEXCEPT_STATEMENT(swap(a.first_data_part_, b.first_data_part_)); ENSURE_NOEXCEPT_STATEMENT(swap(a.second_data_part_, b.second_data_part_)); ... } ... void clean() noexcept { //  clean()  noexcept,    . ENSURE_NOEXCEPT_STATEMENT(first_data_part_.clean()); ENSURE_NOEXCEPT_STATEMENT(second_data_part_.clean()); ... } ... }; 

इसके अलावा, ENSURE_NOT_NOEXCEPT_STATEMENT मैक्रो भी है। इसका उपयोग यह सुनिश्चित करने के लिए किया जाता है कि कॉल के चारों ओर एक अतिरिक्त ट्राइ-कैच ब्लॉक की आवश्यकता है ताकि संभावित अपवाद बाहर न निकलें:

 class some_resource_owner { some_resource resource_; ... public: ~some_resource_owner() noexcept { try { //  release   noexcept,  try-catch     //      . ENSURE_NOT_NOEXCEPT_STATEMENT(release(resource_)); } catch(...) {} ... } ... }; 

हेल्पर मैक्रोज़ STATIC_ASSERT_NOEXCEPT और STATIC_ASSERT_NOT_NOEXCEPT

दुर्भाग्य से, ENSURE_NOEXCEPT_STATEMENT और ENSURE_NOT_NOEXCEPT_STATEMENT मैक्रोज़ का उपयोग केवल कथनों / कथनों के लिए किया जा सकता है, लेकिन उन भावों के लिए नहीं जो एक मान लौटाते हैं। यानी आप इस तरह ENSURE_NOEXCEPT_STATEMENT के साथ नहीं लिख सकते हैं:

 auto resource = ENSURE_NOEXCEPT_STATEMENT(acquire_resource(params)); 

इसलिए, ENSURE_NOEXCEPT_STATEMENT का उपयोग नहीं किया जा सकता है, उदाहरण के लिए, उन छोरों में जहां आपको अक्सर कुछ लिखना पड़ता है:

 for(auto i = something.get_first(); i != some_other_object; i = i.get_next()) {...} 

और आपको यह सुनिश्चित करने की आवश्यकता है कि कॉल get_first() , get_next() , साथ ही i के लिए नए मानों का असाइनमेंट एक अपवाद नहीं फेंकते हैं।

ऐसी स्थितियों से निपटने के लिए मैक्रों STATIC_ASSERT_NOEXCEPT और STATIC_ASSERT_NOT_NOEXCEPT लिखे गए, जिनके पीछे केवल static_assert s छिपे हुए हैं और इससे अधिक कुछ नहीं। इन मैक्रोज़ का उपयोग करके, मुझे किसी भी तरह से परिणाम की आवश्यकता हो सकती है (इस विशेष खंड के संकलन की जाँच नहीं की गई):

 STATIC_ASSERT_NOEXCEPT(something.get_first()); STATIC_ASSERT_NOEXCEPT(something.get_first().get_next()); STATIC_ASSERT_NOEXCEPT(std::declval<decltype(something.get_first())>() = something.get_first().get_next()); for(auto i = something.get_first(); i != some_other_object; i = i.get_next()) {...} 

जाहिर है, यह सबसे अच्छा समाधान नहीं है, क्योंकि यह कोड के दोहराव की ओर जाता है और आगे रखरखाव के साथ इसके "रेंगना" के जोखिम को बढ़ाता है। लेकिन पहले कदम के रूप में, ये सरल मैक्रोज़ उपयोगी साबित हुए।

Noexcept-ctcheck पुस्तकालय

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

क्या noexcept-ctcheck में नहीं मिला (अभी तक?)

मैक्रो ENSURE_NOEXCEPT_EXPRESSION बनाने की इच्छा है, जिसका उपयोग इस तरह किया जा सकता है:

 auto resource = ENSURE_NOEXCEPT_EXPRESSION(acquire_resource(params)); 

पहले सन्निकटन में, वह कुछ इस तरह दिख सकता है:

 #define ENSURE_NOEXCEPT_EXPRESSION(expr) \ ([&]() noexcept -> decltype(auto) { \ static_assert(noexcept(expr), #expr " is expected to be noexcept"); \ return expr; \ }()) 

लेकिन अस्पष्ट संदेह हैं कि कुछ नुकसान हैं जिनके बारे में मैंने नहीं सोचा है। सामान्य तौर पर, हाथ अभी तक ENSURE_NOEXCEPT_EXPRESSION तक नहीं पहुंचे हैं :(

और अगर आप सपने देखते हैं?

मेरा पुराना सपना है कि C ++ में एक नॉइसेप्ट ब्लॉक हो, जिसमें कंपाइलर खुद अपवादों को फेंकने की जाँच करता है और अगर अपवाद फेंके जा सकते हैं तो चेतावनी जारी करता है। मुझे ऐसा लगता है कि इससे अपवाद-सुरक्षित कोड लिखना आसान हो जाएगा। और न केवल ऊपर वर्णित स्पष्ट मामलों में (स्वैप, चाल-संचालक, विध्वंसक)। उदाहरण के लिए, एक noexcept ब्लॉक इस स्थिति में मदद कर सकता है:

 void modify_some_complex_data() { //   . one_container_.modify(); // ,   . ,      . //         try. noexcept { current_age_.increment(); } //    ,      . try { another_container_.modify(); ... } catch(...) { noexcept { //  ,     . current_age_.decrement(); one_container_.rollback_modifications(); } throw; } } 

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

लेकिन शायद एक noexcept block अधिक सामान्य समस्या का एक विशेष मामला है। अर्थात्: प्रोग्रामर की अपेक्षाओं की जाँच करना कि कोड के कुछ ब्लॉक में कुछ गुण हैं। इसे अपवादों की अनुपस्थिति, दुष्प्रभावों की अनुपस्थिति, पुनरावृत्ति की अनुपस्थिति, डेटा दौड़ आदि।

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

निष्कर्ष

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

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