मुझे एहसास है कि जबकि सवाल का कोई भाषा टैग नहीं है, यह संभवतः "कॉफी भाषाओं" के बारे में बात कर रहा है। लेकिन पूर्णता के लिए, मैं C ++ दुनिया में कुछ हद तक स्पष्ट सहमति का उल्लेख करना चाहता हूं।
सी ++ प्रोग्रामर आमतौर पर तीन चीजों में रुचि रखते हैं:
- क्या यह अनुकूलित बिल्ड में शून्य-ओवरहेड होगा? (यह है, यह "बाहर संकलित किया जा सकता है"?)
- क्या मैं उस बिंदु पर डिबगर में फंसने के लिए इसका उपयोग कर सकता हूं जहां त्रुटि का पता चला था?
- क्या मैं घोषित कार्यों से समस्याओं की रिपोर्ट करने के लिए इसका उपयोग कर सकता हूं
noexcept?
अतीत में, मैंने इस तरह कोड लिखकर पहली समस्या का सामना किया है
int
factorial(const int n)
{
if (CHECK_ARGS)
{
if (n < 0)
throw std::invalid_argument {"n < 0"};
}
int fac = 1;
for (int i = 2; i <= n; ++i)
fac *= i;
return fac;
}
जहां CHECK_ARGSहै #defineएक संकलन समय निरंतर करने के लिए d तो संकलक पूरी तरह से सारे तर्क चेकिंग कोड को समाप्त कर सकते हैं अनुकूलित बनाता है। (मैं यह नहीं कह रहा हूं कि चेक को संकलित करना सामान्य रूप से एक अच्छी बात है लेकिन मेरा मानना है कि एक उपयोगकर्ता के पास यह संकलन करने का विकल्प होना चाहिए ।)
मैं अब भी इस समाधान के बारे में पसंद करता हूं कि तर्क जाँच कोड स्पष्ट रूप से एक साथ समूहीकृत दिखाई दे रहा है if। हालांकि, दूसरा और तीसरा मुद्दा इससे हल नहीं होता है। इसलिए, मैं अब assertतर्क की जाँच के लिए एक मैक्रो का उपयोग करने की ओर फिर से झुक रहा हूं ।
बूस्ट मानकों कोडिंग इस बात से सहमत:
प्रोग्रामर त्रुटियों के बारे में क्या?
एक डेवलपर के रूप में, अगर मैंने अपने द्वारा उपयोग किए जा रहे पुस्तकालय के पूर्व शर्त का उल्लंघन किया है, तो मैं स्टैक अनइंडिंग नहीं चाहता हूं। मैं जो चाहता हूं वह एक कोर डंप या समकक्ष है - सटीक बिंदु पर कार्यक्रम की स्थिति का निरीक्षण करने का एक तरीका जहां समस्या का पता चला था। आमतौर पर इसका मतलब है assert()या ऐसा कुछ है।
CppCon'14 में जॉन लैकोस द्वारा डिफेंसिव प्रोग्रामिंग डन राइट ( भाग 1 , भाग 2 ) शीर्षक पर एक बहुत ही दिलचस्प बात की गई थी । अपनी बात के पहले भाग में, उन्होंने अनुबंध के सिद्धांत और अपरिभाषित व्यवहार पर चर्चा की। दूसरे भाग में, वह प्रस्तुत करता है कि मैं व्यवस्थित तर्क जाँच के लिए बहुत अच्छे प्रस्ताव पर क्या विचार करता हूँ। संक्षेप में, वह अभिकथन मैक्रोज़ का प्रस्ताव करता है जो उपयोगकर्ता को यह चुनने की अनुमति देता है कि वह कितना बजट (सीपीयू उपयोग के संदर्भ में) वह तर्क जांच के लिए पुस्तकालय को दान करने के लिए तैयार है और पुस्तकालय में उस बजट का बुद्धिमान उपयोग है। इसके अतिरिक्त, उपयोगकर्ता एक वैश्विक त्रुटि हैंडलिंग फ़ंक्शन भी स्थापित कर सकता है जिसे टूटे हुए अनुबंध का पता चलने पर बुलाया जाएगा।
इस पहलू के बारे में कि एक फ़ंक्शन निजी है, मुझे नहीं लगता कि इसका मतलब है कि हमें कभी भी इसके तर्क की जांच नहीं करनी चाहिए । हम आंतरिक फ़ंक्शन के अनुबंध का उल्लंघन न करने के लिए अपने स्वयं के कोड पर अधिक भरोसा कर सकते हैं, लेकिन हम यह भी जानते हैं कि हम पूर्ण भी नहीं हैं। आंतरिक कार्यों में तर्क की जाँच सिर्फ हमारे स्वयं के बग का पता लगाने में सहायक है क्योंकि यह ग्राहक कोड में बग का पता लगाने के लिए सार्वजनिक कार्यों में है।