2015-12-22 14 views
7

अपवाद सी ++ का एक बड़ा हिस्सा हैं और इसका उपयोग करने के कारणों में से एक (मुझे पता है कि कई और अधिक महत्वपूर्ण, अन्य कारण हैं) अनावश्यक जांच से बचने के लिए है जो if कथनों के साथ कोड को खराब कर देता है (शायद यह गलत है कल्पना?)।क्यों std :: shared_ptr dereference एक शून्य सूचक अपवाद (या समान) फेंक नहीं देता है?

तो अब मैं उत्सुक हूं कि क्यों std::shared_ptr::operator* और std::shared_ptr::operator->null_ptr_exception या इसी तरह फेंक नहीं है?

+0

आप एक स्मार्ट सूचक है कि वर्णित व्यवहार करता है के एक कार्यान्वयन मिला ? – aggsol

+0

@aggsol, नहीं, हम मौजूदा कार्यान्वयन और टेम्पलेट नीतियों का उपयोग करके अपना खुद का निर्माण कर चुके हैं – Samaursa

उत्तर

7

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

इसलिए, स्मार्ट पॉइंटर्स को डिफ्रेंसिंग के लिए व्यवहार को बदलने से कोई अतिरिक्त चेक नहीं करना चाहिए या अपवाद फेंकना चाहिए (यानी, चूंकि कच्चे पॉइंटर्स इस तरह से व्यवहार नहीं करते हैं)।

तृतीय:

मानक करने के लिए स्मार्ट संकेत जोड़ने के लिए प्रस्ताव इस डिजाइन निर्णय (A Proposal to Add General Purpose Smart Pointers to the Library Technical Report) इंगित करता है। डिजाइन फैसले

ए सामान्य सिद्धांत

  1. "के रूप में संभव के रूप में कच्चे प्वाइंटर के निकट, लेकिन कोई क्लोज़र"
+1

उत्तर के लिए धन्यवाद। मुझे यह स्वीकार करना होगा कि मानक समिति का कारण संतोषजनक नहीं है।यदि हम स्मार्ट पॉइंटर्स के साथ विरासत कोड को प्रतिस्थापित करते हैं, तो एक 'null_ptr_exception' को अनचाहे कर दिया जाएगा और प्रोग्राम वैसे भी तोड़ देगा (केवल एक दावा की तरह, हालांकि बिना किसी अवांछित के दिया गया है - फिर फिर, एक दावे की तरह, यह अपवाद तोड़ दिया जा सकता है एक डीबगर द्वारा)। – Samaursa

+1

@ सैमौर्स एक कच्चे सूचक के लिए एक शून्य सूचक ट्रिगर को अपरिवर्तित व्यवहार को ट्रिगर करने के लिए प्रोग्राम पूरी तरह से सामान्य रूप से चलने के लिए प्रतीत होता है लेकिन मैं आपके दृष्टिकोण और निराशा को समझता हूं। –

4

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

+0

लेकिन क्या यह अपवाद/त्रुटि-कोड के लिए/तर्क के लिए तर्क नहीं है? – Samaursa

+1

@ सैमौर्स: नहीं ... एक कच्चे सूचक या मानक लाइब्रेरी स्मार्ट पॉइंटर को संदर्भित करने के लिए मशीन कोड उत्पन्न करने की अनुमति है जो मानता है कि पॉइंटर कभी भी नलप्टर नहीं होगा - कि मशीन कोड कोड से तेज़ी से चलाएगा जिसे जांचना और टालना है (उसी के लिए गैर-नलप्टर मामले) त्रुटि हैंडलिंग कोड के लिए शाखा। चेकिंग/ब्रांचिंग तेज नहीं है, भले ही उस हैंडलिंग को अपवाद या त्रुटि कोड का उपयोग करके पहुंचाया जा सके (जो स्वयं गति और मशीन कोड आकार में भिन्न हो सकते हैं)। –

+0

मैं उम्मीद करता हूं कि 'unique_ptr' का दावा होगा और' shared_ptr') (क्योंकि यह संदर्भ गिनती के साथ पहले से ही भारी वस्तु है और 'weak_ptr's' को 'throw'' पर ट्रैक कर रहा है। फिर भी, यह समझ में आता है क्योंकि एक सूचक अव्यवस्था एक बेहद आम ऑपरेशन है। – Samaursa

संबंधित मुद्दे