त्रुटि संदेश + टेम्पलेट: कुछ सरल टिप्स

गाने के बोल

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



इस तरह के नोट को लिखने का विचार एक प्रोग्राम लिखने की प्रक्रिया में उत्पन्न हुआ जो सक्रिय रूप से बूस्ट :: स्पिरिट 2 का उपयोग करता है - एक जटिल व्याकरण, शब्दार्थ कार्रवाई की एक बहुतायत, विशेषता मान और जैसे के माध्यम से एएसटी का निर्माण। कुछ बिंदु पर, मैंने देखा कि कई त्रुटियों को ठीक करने में मुझे एक या दो मिनट का समय लगा, जबकि परियोजना की शुरुआत में इसी तरह के मामलों में स्थिति का विश्लेषण करने में एक घंटे तक का समय लग सकता है।



सब कुछ gcc के साथ काम के आधार पर लिखा गया है, लेकिन मुझे लगता है कि उपयोग किए गए% compiler_name & के साथ एक सादृश्य खींचना मुश्किल नहीं होगा।



यह साझा करने का समय है!

क्या हमारी मदद करेगा?

• घातक त्रुटियाँ

  
  
  सबसे पहले, आपको कंपाइलर विकल्प को सक्षम करना चाहिए, जो किसी भी त्रुटि को घातक बनाता है। Gcc के मामले में , ये हैं -Watal-त्रुटियाँ । मेटाप्रोग्रामिंग के मामले में, एक समय में एक से अधिक त्रुटि संदेश का अध्ययन करना अभी भी बहुत मायने नहीं रखता है - सबसे अधिक संभावना है, उनमें से पहले को ठीक करने से बहुत बाद वाले प्रभावित होंगे। और पाठ की दीवार बहुत कम होगी।
  
  
  
  

• जड़ में देखता है

  
  
  यदि आप बारीकी से देखते हैं, तो यह पता चलता है कि टेम्प्लेट त्रुटि संदेशों में लगभग निम्न संरचना है:
  
  
  
  

   In file included from %header path%, from %header path%, ... from %source filename%: %header path%: In function '%full name%' %header path%: instantiated from '%full name%' ... %source filename%: instantiated from %full name% ... %header path%: error: %error description%
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

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

• typedef टाइपफ़ेड है

  
  
  समस्याग्रस्त कोड में उपयोग किए जाने वाले बुनियादी टाइफाइड प्रकारों के लिए खोज और प्रतिस्थापन नियमों का एक सेट हाथ में लेना सुविधाजनक है। यहां तक ​​कि एक छोटा एसटीडी :: basic_string <char> std :: string के रूप में बहुत बेहतर दिखता है, अकेले वैक्टर और कतारों के जोड़े की सूचियों के वैक्टर। उदाहरण के लिए, विम में आप एक साधारण रिप्लेसमेंट स्क्रिप्ट लिख सकते हैं, जिसके माध्यम से हर बार एक त्रुटि संदेश चलाने के लिए, अगर यह कुछ पंक्तियों से अधिक लंबा है, और इसे पठनीय बनाते हैं।
  
  
  
  

• पठन स्रोत

  
  
  यदि त्रुटि टेम्पलेट कोड में है, तो हम स्रोत से लगभग एक कदम दूर हैं। जब कोई विचार नहीं होता है कि समस्या क्या हो सकती है, तो लाइब्रेरी हेडर फ़ाइल के उस हिस्से को खोलना सार्थक है जो कंपाइलर (% हेडर पथ%: त्रुटि :) के बारे में शिकायत करता है और एक नज़दीक नज़र आता है। एक नियम के रूप में, यहां तक ​​कि बहुत क्रूर बढ़ावा पुस्तकालयों में, छोटे टुकड़े व्यक्तिगत रूप से पठनीय और समझने योग्य हैं।
  
  

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



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