क्या हमें नो-थ्रो विनिर्देशक के साथ विनाशक प्रदान करना चाहिए?

Question

namespace QuantLib { 

    //! Base error class 
    class Error : public std::exception { 
     public: 
     /*! The explicit use of this constructor is not advised. 
      Use the QL_FAIL macro instead. 
     */ 
     Error(const std::string& file, 
       long line, 
       const std::string& functionName, 
       const std::string& message = ""); 
     /*! the automatically generated destructor would 
      not have the throw specifier. 
     */ 
     ~Error() throw() {} 
     //! returns the error message. 
     const char* what() const throw(); 
     private: 
     boost::shared_ptr<std::string> message_; 
    }; 

} 

जैसा कि आप टिप्पणी के माध्यम से देखते हैं, वर्ग Error का विनाश स्पष्ट रूप से नो-थ्रो विनिर्देशक के साथ एक खाली कार्यान्वयन प्रदान करता है।

प्रश्न: क्या यह आवश्यक है? या क्या यह एक अच्छा अभ्यास है जो संकलक को एक निहित विनाशक उत्पन्न करने की तुलना करता है?

Answer 1

सी ++ 11 में, विनाशक throw() (जब तक किसी भी सदस्य या प्रकार के आधार को एक अलग अपवाद विनिर्देश के साथ विनाशक नहीं है) तो यदि आप सी ++ 11 मोड में संकलित कर रहे हैं तो इसकी कोई आवश्यकता नहीं है।

यदि आप सी ++ 03 में हैं, तो आप इसे जोड़ना चाहेंगे, लेकिन क्या इसका असर होगा या नहीं, बहुत कार्यान्वयन परिभाषित किया गया है ... अब, दस्तावेज़ीकरण उद्देश्यों के लिए आप इसे जोड़ना चाहते हैं, लेकिन फिर से , आमतौर पर यह माना जाता है कि विनाशक फेंक नहीं देते हैं।

Answer 2

Destructors should always be designed to never throw exceptions। तो उस अर्थ में, इसे खाली विनाशक घोषित करने के लिए केवल खाली विनाशक घोषित करने में थोड़ा सा बिंदु है।

Answer 3

आपको लगता है कि throw() का मतलब है।

मानक के अनुसार इसका वास्तव में क्या अर्थ है, "यदि आवश्यक हो तो इस समारोह में प्रत्येक कॉल के आसपास अतिरिक्त कोड डालें, या यह सुनिश्चित करने के लिए कि यह फ़ंक्शन फेंकता है तो अपवाद पकड़ा जाता है और std::unexpected को" ।

कुछ कंप्यूटर्स ने इसका अर्थ यह स्वीकार करने के लिए किया है कि "इस समारोह में कॉल को ऑप्टिमाइज़ करें कि वे फेंक नहीं पाएंगे", लेकिन (मानक के उल्लंघन में) रनटाइम चेक को लागू नहीं किया था।

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

Answer 4

Destructors हमेशा परोक्ष अपवाद विनिर्देशों है:

[class.dtor] 12.4 p3

कि एक अपवाद-विनिर्देश परोक्ष एक ही अपवाद माना जाता है नहीं है एक नाशक का एक घोषणा एक निहित घोषणा के रूप में विनिर्देश (15.4)।

[except.spec] 15.4 p14

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

तो, नहीं, अपवाद विनिर्देश का उपयोग करने के लिए यह आवश्यक नहीं है।

---

सी ++ उपयोगकर्ता 03 परिभाषित विनाशकर्ता में एक अंतर्निहित अपवाद विनिर्देश नहीं था, इसलिए यदि आप अपने खुद के नाशक को परिभाषित करते हैं आप संकलक पर भरोसा नहीं कर सकते स्वचालित रूप से उचित अपवाद विनिर्देश जोड़ने के लिए। लेकिन निस्संदेह घोषित किया गया है कि विनाशकों के पास सी ++ 11 में समान अंतर्निहित अपवाद विनिर्देश है।