आर्टर्ट और नल पॉइंटर सत्यापन का उपयोग

का उपयोग करने के लिए बेहतर क्या है प्रोग्रामिंग करते समय मैं जोरदार संकेत के साथ-साथ नल पॉइंटर सत्यापन का उपयोग कर रहा हूं।आर्टर्ट और नल पॉइंटर सत्यापन का उपयोग

लेकिन जैसा कि मुझे पता है कि जोर केवल DEBUG मोड में उपयोगी होगा।

मेरा प्रश्न मैं एक आंतरिक सूचक जो मुझे यकीन है कि नहीं कर सकते एक सूचक लौटने शून्य उदाहरण समारोह हो रहा है लगता है (लेकिन सूचक वर्ग के एक सदस्य नहीं है) ऐसे मामलों में मैं ज़ोर का उपयोग कर सकते

test* ptr = fun(); // return a pointer of type test 
assert(ptr); 

//do some operation

या शून्य सूचक सत्यापन

test* ptr = fun(); // return a pointer of type test 
assert(ptr); 
if (NULL != ptr) 
{ 
    //do some operation 
}

यहाँ जो कोड अभ्यास मेरी समझ यह दूसरा एक हो जाएगा प्रति good.As है। क्योंकि मुझे कुछ स्थितियों का सामना करना पड़ा है जहां पीआरआर का मान शून्य कुछ असामान्य मामलों के कारण है जिसे हम सोच भी नहीं सकते हैं।

लेकिन क्या हमारे पास कोई अन्य बेहतर विकल्प है?

स्रोत

2013-01-11 Astro - Amit

इस प्रश्न को बंद करने के लिए क्यों मतदान किया जाता है? यह एक वैध सवाल है। – Nawaz

क्या आपने शून्य को वापस नहीं माना है? कोड लिखना बहुत आसान होगा। अर्थात। खाली सरणी/विशेष [शून्य वस्तुओं] (http://en.wikipedia.org/wiki/Null_Object_pattern) और अपवादों को शून्य की वापसी की आवश्यकता को सीमित कर सकते हैं और इसलिए इसकी जांच कर सकते हैं। –

@AlexeiLevenkov दूसरे मामले की जांच –

वास्तविक समाधान फ़ंक्शन fun के अर्थात् पर निर्भर करता है।

तो लौट NULL शब्दार्थ अमान्य है, तो मुझे लगता है कि fun बजाय NULL लौटने का (जैसे std::logic_error के रूप में) एक उचित अपवाद फेंक चाहिए, और आप कॉल साइट पर assert का उपयोग सुनिश्चित करना है कि fun ठीक काम कर रहा है कर सकता है, और यदि यह ठीक काम नहीं कर रहा है, तो कार्यक्रम को रद्द करें। इस तरह, fun में बग शेष कार्यक्रम के लिए प्रचार नहीं करता है, क्योंकि इसे तुरंत पकड़ा जाता है।

हालांकि, अगर लौटने fun से NULL शब्दार्थ वैध है, तो आप कॉल-साइट if और assert वास्तव में इस मामले में की जरूरत नहीं है के प्रयोग पर वापसी मान, जाँच क्योंकि आप if वैसे भी उपयोग करेगा चाहिए।

^{1. या आप std::runtime_error या std::domain_error का उपयोग कर सकते हैं।}

स्रोत

2013-01-11 06:58:37 Nawaz

कुछ असामान्य परिदृश्य ** मजेदार ** द्वारा उस परिवर्तनीय के लिए शून्य या स्मृति भ्रष्टाचार के रूप में मूल्य वापसी कर सकते हैं। तो कुछ अन्य धागे भी। आखिरकार मुझे दूसरे मामले का उपयोग करने के लिए मजबूर करने का मतलब है ... –

जैसा कि आपने बताया है, दावा केवल डीबग के दौरान होता है, प्रोग्रामर की पहचान करने में सहायता करता है कि वे कहां गलत हो गए हैं। इसका उत्पादन में कोई मूल्य नहीं है और इसलिए, यदि आपको कोई संदेह है कि पॉइंटर नल हो सकता है तो मैं दूसरी विधि का उपयोग करना पसंद करता हूं।

स्रोत

2013-01-11 06:57:10 Kiran

हाँ मैं दूसरी विधि पसंद करता हूं .... लेकिन मजेदार() आदर्श आदर्श रूप से वापस नहीं आ सकता है। तो एक अतिरिक्त शर्त जांच नहीं है या हमेशा सुरक्षित पक्ष होने के साथ एक सुरक्षित गेम खेलना है :-) –

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

@ चार्ल्सबैली मुझे पॉइंटर वैल्यू को कभी भी न्यूल होने पर संदेह नहीं है। –

मैं आपको सलाह के लिए अपने कोड का उपयोग करने की सलाह देता हूं। जैसा आपने कहा था, केवल डीबग मोड में काम करता है।

तो, अगर यह रिलीज मोड में काम कर रहा है, तो यह काम नहीं करता है।

यदि आप अपने स्वयं के दावा कोड का उपयोग करते हैं। आप बस यह पता लगा सकते हैं कि यह क्या गलत है।

test* ptr = fun(); // return a pointer of type test 
MyOwnAssert(ptr); 

void MyOwnAssert(void* pPointer) 
{ 
    if (NULL == pPointer) 
    abort(); 
}

स्रोत

2013-01-11 07:06:12 VariOov

उपर्युक्त कोड में आप NULL के लिए जांच नहीं करते हैं और मुझे लगता है कि ऊपर दिए गए कोड को –

हाँ के बजाय मैक्रो का उपयोग करके सरलीकृत किया जा सकता है। लेकिन, यहां पर यह मुद्दा नहीं है। – VariOov

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

यदि आप वास्तव में जोर देते हैं और आपको एक शून्य सूचक पर रोकना है तो अपने रिलीज निर्माण में आवेषण सक्षम करें या वैकल्पिक रिलीज-सक्षम जोर प्रणाली का उपयोग करें।

डीबग-केवल जोर देने का एकमात्र कारण एक तर्क त्रुटि के लिए एक चेक है जो रिलीज कोड में बहुत महंगा है। आम तौर पर एक सूचक के लिए एक शून्य जांच इस श्रेणी में फिट नहीं होगा।

स्रोत

2013-01-11 07:08:02

जो भी आप जोर देते हैं वह आपकी पसंद है: यदि आप चाहें तो उत्पादन में उपयोग कर सकते हैं।

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

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

स्रोत

2013-01-11 07:11:41 Gui13

क्या आप एक छोटे नमूने के साथ ** Google ब्रेकपैड ** के बारे में बहुत कुछ समझा सकते हैं? –

क्या आपने http://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide नहीं किया था? – Gui13

आर्टर्ट और नल पॉइंटर सत्यापन का उपयोग

उत्तर

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