😉 👩🏽‍🚀 🏿 C ++ अपवादों को संभालने के बारे में इतना कठिन क्या है? 🏎️ 👊 👨🏽‍💻

अपवाद और संबंधित स्टैक प्रचार C ++ में सबसे अच्छी तकनीकों में से एक हैं। अपवाद हैंडलिंग प्रोग्राम के ब्लॉक संरचना के साथ सहज रूप से सुसंगत है। बाहरी रूप से, अपवाद हैंडलिंग बहुत तार्किक और स्वाभाविक लगता है।

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

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

यहां जारी है ।
चीजें कैसी चल रही हैं?

अपवाद हैंडलिंग को लागू करने के लिए दो दृष्टिकोण हैं:

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

कुछ उदाहरण:

जीसीसी / एसजेएलजे । SJLJ सेटजम्प / लॉन्गजम्प के लिए छोटा है। इसके बजाय, यह पहले दृष्टिकोण को संदर्भित करता है, लेकिन नियंत्रण हस्तांतरण योजना के लिए धन्यवाद, इसमें प्रत्येक प्रयास के लिए एक निश्चित शुल्क भी है। संक्षेप में, इस कार्यान्वयन में सभी दृष्टिकोणों में निहित सभी खराब को शामिल किया गया है। चौथे संस्करण तक, यह मुख्य अपवाद हैंडलिंग विकल्प था।
जैसा कि नाम से ही स्पष्ट है कि नियंत्रण का हस्तांतरण कॉल के माध्यम से longjmp तक किया जाता है, प्रत्येक कोशिश सेटजम्प में कॉल उत्पन्न करती है। प्रत्येक प्रयास ब्लॉक के लिए स्टैक पर संबंधित बफर आवंटित किया गया है।
प्रत्येक फ़ंक्शन की शुरुआत में, एक प्रोलॉग बनाया जाता है जो संदर्भ स्टैक में वर्तमान फ़्रेम को पंजीकृत करता है। इसी तरह, एक उपसंहार बनाया जाता है जो संदर्भ के शीर्ष से वर्तमान संदर्भ को हटा देता है। संसाधनों को साफ़ करने के लिए प्रत्येक फ़ंक्शन के बगल में एक सहायक कोड बनाया जाता है।
अधिक सटीक रूप से, कंपाइलर फ़ंक्शन से प्रत्येक रिटर्न को लॉग करता है, संभावित रूप से एक अपवाद के साथ समाप्त होने में सक्षम है, एक कुंजी के रूप में, मान सफाई कोड का एक संकेतक है, जिसे फ़ंक्शन के संदर्भ को साफ़ करने के लिए इस स्थान पर लिया जाना चाहिए। लिंकर प्रत्येक लिंक मॉड्यूल के लिए इन पेड़ों के टुकड़ों को एक एकल प्रोजेक्ट ट्री (बहुत खुरदरा) में इकट्ठा करता है। इस चमत्कार को एलएसडीए (भाषा विशिष्ट डेटा क्षेत्र) कहा जाता है और यह ".gcc_except_table" अनुभाग में स्थित है।
यदि कोई अपवाद होता है, तो फेंके गए अपवाद के type_info के आधार पर, एक ब्लॉक खोजा जाता है जो इस अपवाद को संभाल सकता है। वर्तमान संदर्भ से शुरू होकर हैंडलर संदर्भ तक (कॉल फ़्रेम पर नेविगेशन का उपयोग करके), कोड के पते निकाले और निष्पादित किए जाते हैं, जो (स्थानीय चर के दायरे के आधार पर) इस स्थान पर निष्पादित होने चाहिए। फिर नियंत्रण स्थानांतरित किया जाता है।

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

लेकिन जो वास्तव में आपकी आंख को पकड़ता है, वह है स्वैच्छिक सहायक कोड, विशेषकर गैर-तुच्छ मामलों में। कंपाइलर, YACC की तरह, स्टैक मशीन के सभी राज्यों को पेंट करता है। और, हालांकि, आशावादी, यदि संभव हो, तो अतिरेक और तुच्छ कोड को साफ करता है, जो अवशेष पर्याप्त से अधिक है।
GCC / DW2 । यह अपवादों को संभालने के लिए पहले दृष्टिकोण का एक उदाहरण है। DW2 का अर्थ है DWARF2 (अब 3 पहले से ही) - सहायक स्टोर करने के लिए एक प्रारूप, जिसमें निष्पादन योग्य फ़ाइल में जानकारी डीबग करना शामिल है। आखिरकार, डिबगिंग जानकारी की भी आवश्यकता है ताकि किसी भी समय किसी भी चर के मूल्य का पता लगाना संभव हो, जिसमें पिछले (ऊपरी) कॉल के फ्रेम शामिल हैं। इसलिए, कोड जनरेशन की प्रक्रिया में, कंपाइलर इस बात की जानकारी देता है कि यह स्टैक पर क्या आवंटित करता है, जिसमें यह रजिस्टरों को रखता है, जब वे इसे स्टोर करते हैं ... दरअसल, यह प्रारूप DWARF के समान नहीं है, हालांकि यह इसके बहुत करीब है। जीसीसी के चौथे संस्करण के लिए मानक।

वैचारिक रूप से, कॉल के उच्च फ्रेम में आने की जानकारी कार्यक्रम कोड के प्रत्येक पते पर संग्रहीत की जाती है। व्यवहार में, इस जानकारी की मात्रा के कारण, यह संकुचित है, वास्तव में, यह बाइट कोड की व्याख्या का उपयोग करके गणना की जाती है। अपवाद होने पर इस बायोटेक को निष्पादित किया जाता है। यह सब ".eh_frame" और ".hh_frame_hdr" अनुभागों में स्थित है।
हां, अन्य बातों के अलावा, DWARF दुभाषिया एक उत्कृष्ट बैकडोर है, जिसकी सहायता से, बायटेकोड को बदलकर, आप अपवाद को पकड़ सकते हैं और इसे प्रसंस्करण के लिए भेज सकते हैं जहाँ भी आप चाहें।
जीसीसी / डीडब्ल्यू 2 जीसीसी / एसजेएलजे के रूप में लगभग एक ही एलएसडीए अनुभाग का उपयोग करता है।

जैसा कि हम देख सकते हैं, स्टैक प्रमोशन (अपवादों के अभाव में) से जुड़ी लागत व्यावहारिक रूप से अनुपस्थित है। हालांकि, एक अपवाद को बढ़ाने की लागत अधिक है। इसके अलावा, कोई भी कंपाइलर और उसके बजाय उच्च-स्तरीय परतों के आर्किटेक्चर-निर्भर हिस्से के मजबूत एकीकरण को नोट करने में विफल हो सकता है।
एमएस वीसी ++ । यह संकलक एक दूसरी प्रसंस्करण रणनीति लागू करता है।
- संभावित रूप से अपवादों को फेंकने वाले प्रत्येक फ़ंक्शन के लिए, कंपाइलर एक स्टैक चर के रूप में एक पॉइंटर से पिछले समान संरचना, हैंडलर फ़ंक्शन के पते और सहायक डेटा के रूप में बनाता है। इस संरचना का पता FS में दर्ज किया गया है: [0], जो इन संरचनाओं के ढेर के ऊपर है। Win32 में FS रजिस्टर का उपयोग थ्रेड इनफार्मेशन ब्लॉक ( TIB ) (Win64 में GS) के रूप में किया जाता है। यह एक हैंडलर फ़ंक्शन (अपने स्वयं के डेटा सेट के साथ) और एक उपसंहार भी बनाता है जो एफएस को पुनर्स्थापित करता है: [०] यदि सफल हो।
- कंपाइलर फ़ंक्शन में प्रत्येक कोशिश-ब्लॉक के लिए तत्व द्वारा - संरचनाओं की एक तालिका बनाता है। प्रत्येक कोशिश-ब्लॉक में एक निश्चित राज्य के अनुरूप इस तालिका में एक प्रारंभ और अंत सूचकांक होता है (एक नेस्टेड ब्लॉक में एक नेस्टेड अंतराल होता है), और संकलक खुद इस सूचकांक की प्रासंगिकता पर नजर रखता है। इस तरह, संकलक कोशिश ब्लॉकों के ढेर को लागू करता है।
- प्रत्येक कोशिश-ब्लॉक के लिए, एक कैच-ब्लॉक तालिका शुरू की जाती है। प्रत्येक प्रकार के अपवाद के लिए, इस प्रकार के अपवाद के पदानुक्रम में सभी बेस कक्षाओं के लिए एक type_info तालिका बनाई जाती है।
- प्रत्येक फ़ंक्शन के लिए एक खोल तालिका बनाई गई है, जिसमें से प्रत्येक तत्व में एक फ़ंक्शन के लिए एक संकेतक होता है जो कुछ संसाधन और पिछले तत्व की संख्या को मुक्त करता है। एक तालिका में कई श्रृंखलाएं हो सकती हैं, जो विनाशकों के साथ वस्तुओं के दायरे पर निर्भर करती हैं। अपवाद के समय, वर्तमान स्थिति के सूचकांक के अनुसार, जो ऊपर उल्लेख किया गया था, आप आवश्यक श्रृंखला पा सकते हैं और सभी आवश्यक प्रोसेसर को कॉल कर सकते हैं।
- संस्करण x64 के लिए, सहायक स्टैक संरचनाएं, यदि संभव हो तो, .pdata में स्थानांतरित कर दी गई थीं; संभवतः, एमएस पहली रणनीति को बहुत आशाजनक मानता है।
- जब एक अपवाद को फेंक दिया जाता है, तो मुख्य कार्य ऑपरेटिंग सिस्टम द्वारा किया जाता है, जहां नियंत्रण SYSENTER के माध्यम से होता है।
इस पद्धति में एसजेएलजे के समान कमियां हैं - व्यापक सहायक कोड और कम पोर्टेबिलिटी।
एक अपवाद को बढ़ाने और हर जगह उपयुक्त कैच ब्लॉक चुनने की प्रक्रिया लगभग समान दिखती है:
- जब कोई अपवाद फेंका जाता है, तो उसका डिस्क्रिप्टर बनाया जाता है, जिसमें ऑब्जेक्ट की एक कॉपी होती है, उसका type_info, डिस्ट्रक्टर को एक पॉइंटर
- ट्राई ब्लॉक के ढेर के साथ उठना और सभी पंजीकृत स्टैक्ड ऑब्जेक्ट्स को साफ़ करना (इस स्टैक पर नेविगेशन हर जगह अलग है, लेकिन सार एक ही है), हम कैच ब्लॉक की सूचियों को देखते हैं और एक उपयुक्त की तलाश करते हैं।
- यदि एक उपयुक्त कैच ब्लॉक पाया जाता है, तो अपवाद ऑब्जेक्ट एक स्थानीय चर बन जाता है; हम इस ब्लॉक को कहते हैं। यदि संदर्भ के बजाय कैच ब्लॉक मान से अपवाद लेता है, तो इसकी एक प्रति बनाई जाएगी।
- यदि कोई अपवाद फिर से कॉल नहीं था, तो ऑब्जेक्ट को छोड़ दें - अपवाद
- "नोट के लिए मालकिन":
```
some_exception exc("oioi"); throw exc; 
```
  एक अतिरिक्त कॉपी कंस्ट्रक्टर / विध्वंसक बनाता है
```
 throw *new some_exception("oioi"); 
```
  एक स्मृति रिसाव देता है
```
 catch(some_exception exc) ... 
```
  फिर से निर्माता और विध्वंसक के लिए एक अतिरिक्त कॉल
```
 catch(const some_exception *exc) ... 
```
  जब तक आप पॉइंटर नहीं छोड़ते तब तक एक अपवाद उड़ जाएगा
```
 throw some_exception("oioi"); ... catch (const some_exception &exc).... 
```
  न्यूनतम लागत

विवरण यहाँ , यहाँ और यहाँ देखा जा सकता है ।

क्या होगा अगर ...
और, ऐसा लगता है, यह सब करने और ऐसा करने की बात है - सही क्रम में विनाशकों को कॉल करने के लिए, जिनके शरीर पहले से मौजूद हैं। यह कैसे हुआ कि एक साधारण, सामान्य रूप से, कार्य में इस तरह के चिपचिपा, भारी और, स्वतंत्र रूप से विकसित समाधान हैं? यह कहना मुश्किल है, इसलिए ऐतिहासिक रूप से।
आइए, समाधान को रेखांकित करने का प्रयास करें, इसे सरल छोड़ने की कोशिश करें और, यदि संभव हो तो, वास्तुशिल्प रूप से स्वतंत्र।

सबसे पहले, हम एक रणनीति चुनते हैं - यह दूसरा विकल्प होगा।
कंट्रोल ट्रांसफर - setjmp / longjmp
हम एक संरचना बनाते हैं, जिनके सभी वंशज संभावित पदोन्नति के लिए स्वयं को पंजीकृत करने की क्षमता रखते हैं।
```
 struct unw_item_t { unw_item_t (); virtual ~unw_item_t (); void unreg(); unw_item_t *prev_; }; 
```

और एक और, जिसका दायरा एक प्रयास-खंड है

 struct jmp_buf_splice { jmp_buf_splice (); ~jmp_buf_splice (); jmp_buf buf_; jmp_buf_splice *prev_; unw_item_t objs_; };

सादगी के लिए, हम केवल कास्ट चार * अपवादों को फेंक देंगे
```
  extern int throw_slice (const char *str); 
```

एक कोशिश ब्लॉक अनुकरण करने के लिए कई मैक्रोज़

 //   #define TRY_BLOCK { \ jmp_buf_splice __sl; \ const char *__exc = (const char *)setjmp (__sl.buf_); \ if (NULL == __exc) { ... // -  catch(…) ..    const char* #define CATCH_BLOCK_FIN \ } else { ... //   #define FIN_BLOCK \ } \ } ... //   #define THROW_IN_BLOCK(exc) \ throw_slice (exc); ... //   , __exc   TRY_BLOCK #define RETHROW_IN_BLOCK \ throw_slice (__exc);

अब jmp_buf_splice वर्ग के सदस्यों के शव दिखाएं:
```
 static jmp_buf_splice *root_slice_ = NULL; jmp_buf_splice::jmp_buf_splice () { objs_ = NULL; prev_ = root_slice_; root_slice_ = this; } jmp_buf_splice::~jmp_buf_splice () { root_slice_ = prev_; } 
```
यहां एकल-थ्रेडेड कार्यान्वयन के लिए एक विकल्प है। यदि root_slice_ के बजाय कई थ्रेड्स हैं, तो हमें उदाहरण के लिए, GCC के समान, TLS का उपयोग करना होगा।

अब अनजाने वर्ग के सदस्यों का समय आ गया है:

 unw_item_t::unw_item_t () { if (NULL != root_slice_) { prev_ = root_slice_->objs_; root_slice_->objs_ = this; } } unw_item_t::~unw_item_t () { unreg(); } unw_item_t::unreg () { if (NULL != root_slice_ && (prev_ != reinterpret_cast<unw_item_t *>(~0))) { root_slice_->objs_ = prev_; prev_ = reinterpret_cast<unw_item_t *>(~0); } }

अब एक अपवाद बढ़ाने और ढेर को बढ़ावा देने की प्रक्रिया पर विचार करें:

 static int pop_slice () { jmp_buf_splice *sl = root_slice_; assert (NULL != sl); root_slice_ = sl->prev_; return 0; } int throw_slice (const char *str, bool popstate) { if (NULL == str) return -1; jmp_buf_splice *sl = root_slice_; unw_item_t *obj = root_slice_->objs_; while (NULL != obj) { unw_item_t *tmp = obj; obj = obj->prev_; tmp->~unw_item_t (); } if (popstate) pop_slice (); longjmp (sl->buf_, int(str)); return 0; }

सेवा वर्ग - std का एनालॉग :: auto_ptr:

  template<typename cl> class deleter_t : public unw_item_t { public: deleter_t (cl *obj){ptr_ = obj;}; virtual ~deleter_t () {delete ptr_;}; private: cl *ptr_; deleter_t (); deleter_t (const deleter_t &); deleter_t &operator= (const deleter_t &); };

सेवा वर्ग - सरणी:

 template<typename cl> class vec_deleter_t : public unw_item_t { public: vec_deleter_t (cl *obj){ptr_ = obj;}; virtual ~ vec_deleter_t () {delete [] ptr_;}; private: cl *ptr_; vec_deleter_t (); vec_deleter_t (const vec_deleter_t &); vec_deleter_t &operator= (const vec_deleter_t &); };

उदाहरण।

टेस्ट क्लास

 class _A { public: _A():val_(++cnt_){printf ("A::A(%d)\n",val_);} _A(int i):val_(i){printf ("A::A(%d)\n",val_);} virtual ~_A(){printf ("A::~A(%d)\n",val_);} static int cnt_; }; int _A::cnt_ = 0; class A : public unw_item_t, _A {};

उदाहरण 1

 A a(1); TRY_BLOCK { A b(2); THROW_IN_BLOCK("error\n"); std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << __exc; } FIN_BLOCK;

ए :: ए (1)
A :: A (2)
ए :: ~ ए (2)
त्रुटि
ए :: ~ ए (1)

उदाहरण 2

 A a(1); TRY_BLOCK { A b(2); TRY_BLOCK { A c(3); THROW_IN_BLOCK("error\n"); std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << "." << __exc; RETHROW_IN_BLOCK; } FIN_BLOCK; std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << ".." << __exc; } FIN_BLOCK;

ए :: ए (1)
A :: A (2)
A :: A (3)
ए :: ~ ए (3)
.त्रुटि
ए :: ~ ए (2)
..error
ए :: ~ ए (1)

उदाहरण 3

  TRY_BLOCK { vec_deleter_t<_A> da(new _A[3]); TRY_BLOCK { THROW_IN_BLOCK("error\n"); std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << "." << __exc; RETHROW_IN_BLOCK; } FIN_BLOCK; std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << ".." << __exc; } FIN_BLOCK;

ए :: ए (1)
A :: A (2)
A :: A (3)
.त्रुटि
ए :: ~ ए (3)
ए :: ~ ए (2)
ए :: ~ ए (1)
..error

प्रतिबंध
इस समाधान के बहुत सारे नुकसान हैं:

आप विध्वंसक में अपवाद नहीं फेंक सकते। Unw_item_t विध्वंसक ने अभी तक इस उदाहरण के लिंक को हटाया नहीं है, परिणामस्वरूप, विध्वंसक को फिर से बुलाया जाएगा।
नए ऑपरेटर के उपयोग से unw_item_t से विरासत में मिली कक्षा का एक ऑब्जेक्ट बनाना बहुत खतरनाक है। यहां तक कि अगर कोई स्वयं स्मृति का ख्याल रखता है, तो ऐसा सूचक एक विदेशी संदर्भ में या यहां तक कि एक विदेशी धारा में गिर सकता है, एक वस्तु जिसे वह देख रहा है वह अचानक विनाशकारी हो सकता है, जिसके परिणामस्वरूप एक चयापचय तबाही होगी।
Unw_item_t से विरासत में मिला एक वर्ग दूसरे वर्ग के सदस्य के रूप में एकत्र नहीं किया जा सकता है, अन्यथा इसके विनाशकर्ता को दो बार कहा जाएगा।
वर्णित पद्धति को हार्डवेयर अपवादों के साथ एकीकृत नहीं किया जा सकता है।
अपवाद प्रकारों पर प्रतिबंध। ऊपर, हमने केवल एक स्ट्रिंग पॉइंटर का उपयोग किया। यदि आप एक अपवाद के रूप में आदिम प्रकार पास करते हैं, तो केवल एक विकल्प हो सकता है। यदि हम एक अपवाद के रूप में ऑब्जेक्ट पॉइंटर का उपयोग करते हैं, तो हम RTTI का उपयोग कर सकते हैं। आप ऐसा कुछ सुझा सकते हैं
```
 #define CATCH_BLOCK_TYPED(t) \ } else if (NULL != dynamic_cast<t>(__exc)) { 
```
और यह हमें विभिन्न प्रकार के अपवादों का उपयोग करने का अवसर देगा। लेकिन फिर आदिम प्रकार के अपवादों को फेंकना असंभव है।
उपयोगकर्ता को फेंके गए अपवाद ऑब्जेक्ट को हटाना होगा।

और अभी तक।
वर्णित सीमाओं के बावजूद, वर्णित विधि में निहित लाभ हैं:

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

क्या इस पद्धति के नुकसान को खत्म करना संभव है, जबकि इसके फायदे बरकरार रहते हैं? हाँ और नहीं। केवल C ++ टूल का उपयोग करना, यह संभव नहीं है।

लेखक किस समय गाड़ी चला रहा है?
तकनीकी प्रलाप के क्रम में, हम उपरोक्त योजना को सही ढंग से लागू करने के लिए संकलक को संशोधित करने के तरीके के बारे में सोचेंगे?
उपरोक्त समाधान में क्या गायब था? वस्तु कैसे उत्पन्न हुई इसका ज्ञान।
उदाहरण के लिए, यदि कोई वस्तु आम ढेर से आवंटित मेमोरी पर बनाई गई है और थ्रेड्स के बीच माइग्रेट कर सकती है, तो इसे किसी भी तरह से स्ट्रीम-निर्भर स्टैक पर पंजीकृत नहीं होना चाहिए। आपको किसी वस्तु को किसी अन्य वस्तु में कहीं भी एकत्र नहीं करना चाहिए।
और एक ही प्रकार की वस्तु के साथ, लेकिन स्टैक मेमोरी पर, यह किया जाना चाहिए। बेशक, इस स्टैक ऑब्जेक्ट के लिए किसी अन्य थ्रेड के लिए एक पॉइंटर पास करना संभव है, लेकिन यह कल्पना करना मुश्किल है कि यह किस स्थिति में उपयोगी हो सकता है।
तो:

टाइप टी के स्टैक ऑब्जेक्ट्स के लिए , कंपाइलर वास्तव में टाइप का एक रैपर क्लास बनाता है
```
 template<class T> class __st_wrapper : public unw_item_t { public: virtual ~__st_wrapper() { unreg(); ((T*)data_)->T::~T(); }; private: char data_[sizeof(T)]; }; 
```
साथ ही वांछित निर्माता टी को बुलाकर ।
Jmp_buf_splice :: root_slice_ वर्ग का स्थिर सदस्य टीएलएस के माध्यम से या संबंधित रजिस्टर के माध्यम से लागू किया जाता है, यदि कोई हो
प्रोग्रामर अभी भी डेटा में स्थित टाइप T का केवल एक ऑब्जेक्ट देखता है
वर्चुअल डिस्ट्रक्टर्स के बिना स्टैक्ड ऑब्जेक्ट के लिए, यह आवरण में दिखाई देता है
अब विनाशकों में अपवादों को फेंकना संभव है विध्वंसक खुद को बुलाने से पहले, हम डेरेगिस्टर कर रहे थे।
हम हार्डवेयर अपवादों (कर्नेल अपवादों) का समर्थन नहीं करते हैं, इसलिए, अपवाद को फेंक दिए जाने के समय, कंपाइलर जानता है कि कौन सा रजिस्टर "लैंडेड" होना चाहिए और ऐसा करना चाहिए
स्टैक ऑब्जेक्ट्स के नियमित विनाश के लिए, कंपाइलर __st_wrapper के डिस्ट्रक्टर्स को कॉल करता है
उपयुक्त कैच ब्लॉक को चुनने की व्यवस्था इस प्रकार है। यानी कोड के बाहर इन ब्लॉकों के विवरणों के साथ हमें अभी भी सहायक तालिका जानकारी की आवश्यकता है।
हम सेटजम्प के एनालॉग का उपयोग करके नियंत्रण स्थानांतरित करेंगे। यह एक मध्यवर्ती (ऊपर वर्णित दो के संबंध में) नियंत्रण हस्तांतरण विकल्प को लागू करने का प्रस्ताव है। सेटजम्प में एक महत्वपूर्ण कमी है - बफर का आकार काफी बड़ा है, जबकि इसका छोटा हिस्सा वास्तव में उपयोग किया जाता है।
दूसरी ओर DWARF बाइटकोड निष्पादन बहुत ही बेकार लगता है।
इसलिए, सेटजम्प बफर के बजाय, हम रजिस्टरों की एक सूची को संग्रहीत करने की आवश्यकता होगी जो स्टैक पॉइंटर के सापेक्ष वसूली और बदलाव की आवश्यकता होगी, जहां वास्तविक मूल्य हैं। एक गणना मूल्य के मामले में, मूल्य सीधे रजिस्टर में संग्रहीत किया जाता है। ऐसा करने के लिए, अतिरिक्त मेमोरी को स्टैक पर आवंटित किया जाता है और इसे एक शिफ्ट दिया जाता है। वास्तव में, एक अस्थायी चर शुरू किया जाता है।
एक अपवाद को बढ़ाने से पहले, कंपाइलर सभी प्रासंगिक डेटा को रजिस्टरों से अनलोड करता है, जिस स्थिति में इसे बिना नुकसान के बहाल किया जा सकता है।

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

वैसे।

एक वस्तु यह पता लगा सकती है कि यह एक स्टैक है। ऐसा करने के लिए, यह वर्तमान थ्रेड के स्टैक सेगमेंट के भीतर होना चाहिए।
तो आप ऑब्जेक्ट को हुक से हटा सकते हैं? मैं कल्पना नहीं कर सकता कि इसकी आवश्यकता क्यों हो सकती है, लेकिन ऐसा अवसर मौजूद है।
यदि आप इसे उतार सकते हैं, तो आप इसे लगा सकते हैं। एलोका के माध्यम से स्टैक पर मेमोरी आवंटित करें, कंस्ट्रक्टर को कॉल करने के लिए मजबूर करें, और इसे स्टैक प्रमोशन तंत्र से कनेक्ट करें।
अलग डेटा और नियंत्रण ढेर के साथ आर्किटेक्चर के लिए, एक सूची के बजाय नियंत्रण स्टैक का उपयोग करके अपवाद हैंडलिंग को बहुत कुशलता से लागू किया जा सकता है।

पुनश्च: जानकारीपूर्ण चर्चा के लिए अलेक्जेंडर अर्टुशिन का विशेष धन्यवाद।

C ++ अपवादों को संभालने के बारे में इतना कठिन क्या है?

More articles: