रेफरेंस-टू-कॉन्स्ट के रूप में एक अपवाद क्यों पकड़ा गया?


84

मैंने कई बार सुना और पढ़ा है कि एक अपवाद को संदर्भ के बजाय संदर्भ-टू-कॉन्स्ट के रूप में पकड़ना बेहतर है। यही वजह है कि:

try {
    // stuff
} catch (const std::exception& e) {
    // stuff
}

से बेहतर:

try {
    // stuff
} catch (std::exception& e) {
    // stuff
}

जवाबों:


67

आप की जरूरत है:

  • एक संदर्भ ताकि आप पॉलीमॉर्फिक रूप से अपवाद तक पहुंच सकें
  • प्रदर्शन को बढ़ाने के लिए एक कास्ट, और संकलक को बताएं कि आप ऑब्जेक्ट को संशोधित करने नहीं जा रहे हैं

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


1
"कंपाइलर को बताएं कि आप ऑब्जेक्ट को संशोधित नहीं करने जा रहे हैं" - मान लीजिए कि यदि आप किसी फ़ंक्शन कॉल के पैरामीटर के रूप में ऑब्जेक्ट पास कर रहे हैं तो उपयोगी हो सकता है।
क्रेग मैकक्वीन

1
'पॉलीमॉर्फिक रूप से अपवाद तक पहुँच' से आपका क्या तात्पर्य है?
आम की

3
निश्चित रूप से @mango का अर्थ है कि वर्चुअल फ़ंक्शन (जैसे std::exception' what()फ़ंक्शन) को कॉल करने में सक्षम होना । यदि आप मूल्य से पकड़ते हैं तो आप उस फ़ंक्शन को कॉल नहीं कर सकते और मूल अपवाद विवरण प्राप्त कर सकते हैं।
MM

11
असेंबली में ऐप्पल क्लैंग 7 और gcc 5 द्वारा (ऑप्टिमाइज़ेशन O3 के साथ) देखा गया है और मुझे कॉन्स्ट रेफ़ और नॉन-कॉस्ट रेफ असेंबली के बीच कोई अंतर नहीं दिखता है। इसलिए, मुझे लगता है कि gcc और Apple क्लैंग के अनुकूलन में कोई अंतर नहीं है
Vasiliy Soshnikov

2
संकलक आसानी से देख सकता है कि आप किन वस्तुओं को संशोधित करते हैं और जो नहीं ( एसएसए और निरंतर प्रसार)। एक बेहतर व्याख्या की आवश्यकता है (या यह एक मिथक है?)।
जंग लगी

31

मूल रूप से कोई कारण नहीं है।

अपवाद वस्तुओं को अपने स्वयं के स्मृति स्थान में रहते हैं ताकि आप अस्थायी भाव में बनाए गए अपवादों को पकड़ने के बारे में चिंता की जरूरत नहीं है।

तुम सब कर रहे हैं वादा किया है कि आप अपवाद वस्तु में बदलाव नहीं करेगी, लेकिन जब से अपवाद वस्तुओं अपरिवर्तनीय इंटरफेस होना चाहिए , वहाँ वास्तव में यहाँ व्यावहारिक बात नहीं है।

हालाँकि, जब आप इसे पढ़ते हैं तो यह आपको गर्म और आरामदायक महसूस करवा सकता है - यह मेरे लिए कैसा है!

Own उनके पास अपने स्वयं के, विशेष, थ्रेड-लोकल स्टैक हैं।
डिस्क्लेमर: बूस्ट.एक्सटैक्स इसे फंकी सामान बनाने के लिए तोड़ता है और अपवाद विवरण, पोस्ट-कंस्ट्रक्शन को जोड़ता है। लेकिन यह हैकरी है!


क्या आप कृपया विस्तार से बता सकते हैं Exception objects live in their own memory space? क्या आपके पास इसके बारे में सुझाव देने के लिए एक अच्छा पढ़ा है?
रिचर्ड डैल

@LeFlou: मैं आपको मानक की ओर इशारा कर सकता था, लेकिन यह डीम के लिए थोड़ा भ्रामक होगा कि "एक अच्छा पढ़ा" ...: पी
लाइटनेस दौड़ ऑर्बिट

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

@LeFlou: ठीक है, यह मानक से कहीं अधिक आधिकारिक नहीं मिलता है ....
कक्षा में लाइटनेस दौड़

1
@ रीचर्डली जाँच सी ++ प्राइमर 5 , .1 18.1.1 एक्सपेक्टेशन ऑब्जेक्ट। यह कहता है कि अपवाद ऑब्जेक्ट अंतरिक्ष में रहता है, संकलक द्वारा प्रबंधित किया जाता है, जो कि किसी भी चीज़ को पकड़ने के लिए सुलभ होने की गारंटी है। अपवाद वस्तु पूरी तरह से नियंत्रित होने के बाद नष्ट हो जाती है।
रिक

5

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


2

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

अपवाद हैंडलर, प्लेटफ़ॉर्म विशिष्ट हो सकते हैं, और मज़ेदार स्थानों में अपवाद रख सकते हैं क्योंकि वे उन्हें बदलने की उम्मीद नहीं कर रहे हैं?


-1

उसी कारण से आप एक कास्ट का उपयोग करते हैं।


और इसी कारण से क्यों बिंदुओं पर संदर्भ पसंद करना पसंद करते हैं :-)
दिमित्री सी।

12
सरल और glib, लेकिन वास्तव में जवाब नहीं।
सर्वव्यापी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.