C / C ++ में संकलन-समय सत्यापन

C / C ++ आपको कार्यक्रम के संकलन के चरण में निरंतर अभिव्यक्ति की जांच करने की अनुमति देता है। यह भविष्य में कोड को संशोधित करते समय समस्याओं से बचने का एक सस्ता तरीका है।
मैं इसके साथ काम करने पर विचार करूंगा:

• स्थानांतरण द्वारा (एनम),
• सरणियाँ (एनम के साथ उनका सिंक्रनाइज़ेशन),
• स्विच का निर्माण
• साथ ही विषम डेटा वाले वर्गों के साथ काम करते हैं।

BOOST_STATIC_ASSERT और सभी-सभी

संकलन समय पर कंपाइलर को तोड़ने के कई तरीके हैं। इनमें से, मुझे सबसे अधिक प्रदर्शन पसंद है:

#define ASSERT(cond) typedef int foo[(cond) ? 1 : -1] 

लेकिन यदि आप अपने कार्यक्रम में बढ़ावा का उपयोग करते हैं, तो आपको कुछ भी आविष्कार करने की आवश्यकता नहीं है: BOOST_STATIC_ASSERT । समर्थन भी C ++ 11 (static_assert) में होने का वादा करता है ।

उपकरण के साथ, अब उपयोग के बारे में।

Enum में तत्वों की संख्या को नियंत्रित करें

गणना अर्थ से संबंधित स्थिरांक का एक समूह है, जो आमतौर पर कार्यक्रम तर्क के शाखा बिंदु पर उपयोग किया जाता है। आमतौर पर कई शाखा बिंदु होते हैं, और आप आसानी से कुछ छोड़ सकते हैं।
एक उदाहरण:

 enum TEncryptMode { EM_None = 0, EM_AES128, EM_AES256, <b>EM_ItemsCount</b> }; 

अंतिम तत्व एक एल्गोरिथ्म नहीं है, लेकिन अधिकतम सिमेंटिक तत्व से अधिक नंबर एक के साथ एक सहायक स्थिर है।

अब जहां भी इस सेट से स्थिरांक का उपयोग किया जाता है, आपको बस एक चेक जोड़ने की आवश्यकता है:

 ASSERT(EM_ItemsCount == 3); 

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

EM_ItemsCount की शुरूआत से एक बोनस के रूप में, फ़ंक्शन मापदंडों के रनटाइम-चेक सम्मिलित करना संभव हो जाता है:

 assert( 0 <= mode && mode < EM_ItemsCount ); 

इस तरह के एक स्थिर विकल्प के साथ तुलना करें:

 assert( 0 <= mode && mode <= EM_AES256 ); 

(EM_AES512 जोड़ें और गलत जांच प्राप्त करें)

एरे और एनम

पिछले अनुभाग से सत्यापन का एक विशेष मामला।
मान लें कि हमारे पास समान एन्क्रिप्शन एल्गोरिदम के लिए मापदंडों के साथ एक सरणी है (उदाहरण उंगली से थोड़ा चूसा जाता है, लेकिन जीवन में ऐसे ही मामले हैं):

 static const ParamStruct params[] = { { EM_None, 0, ... }, { EM_AES128, 128, ... }, { EM_AES256, 256, ... }, { -1, 0, ... } }; 

इस संरचना को TEncryptMode के साथ समकालिक रखना आवश्यक है।
(मुझे सरणी के अंतिम तत्व की आवश्यकता क्यों है, मुझे लगता है, समझाने की आवश्यकता नहीं है।)

सरणी की लंबाई की गणना करने के लिए हमें एक सहायक स्थूल की आवश्यकता होगी:

 #define lengthof(x) (sizeof(x) / sizeof((x)[0])) 

अब, आप एक चेक लिख सकते हैं (बेहतर होगा यदि सही params परिभाषा के बाद):

 ASSERT( lengthof(params) == EM_ItemsCount + 1 ); 

अपडेट: टिप्पणियों में , स्कोटर हब्रायुज़र ने लंबाई के मैक्रो का एक सुरक्षित संस्करण सुझाया, धन्यवाद जिसके लिए मैं हूं।

स्विच

यहां सब कुछ स्पष्ट है (ऊपर दिए गए उदाहरणों के बाद)। स्विच (मोड) जोड़ने से पहले:

 ASSERT(EM_ItemsCount == 3); 

थोड़ा कम स्पष्ट रनटाइम चेक:

 ASSERT(EM_ItemsCount == 3); switch( mode ) { case ...: ... break; ... <b>default: assert( false );</b> } 

गलतियों के खिलाफ बचाव के लिए एक अतिरिक्त गढ़। यदि क्रियाओं को उसी तरह से संसाधित किया जाता है, तो एक कार्रवाई के लिए कई मामले-स्थितियों को सूचीबद्ध करना बेहतर होता है, डिफ़ॉल्ट रूप से निर्बाध छोड़ना:

 ... case ET_AES128: case ET_AES256: ... break; ... 

विषम डेटा वाली कक्षाएं

आइए हम एनुमोव से दबें और ऐसी कक्षा देखें:

 class MyData { ... private: int a; double b; ... }; 

यह अच्छी तरह से हो सकता है कि भविष्य में किसी समय, कोई व्यक्ति इसमें एक इंट सी चर जोड़ना चाहेगा। इस समय तक वर्ग बड़ा और जटिल हो गया। चर सी लिखने के लिए अंक कैसे खोजें?

इस तरह की एक अर्ध-स्वचालित समाधान विधि प्रस्तावित है - हमने कक्षा में एक डेटा संस्करण निरंतर स्थापित किया है:

 class MyData { static const int DataVersion = 0; ... }; 

अब, सभी तरीकों में जिसमें सभी डेटा की अखंडता को ट्रैक करना महत्वपूर्ण है, आप लिख सकते हैं:

 ASSERT(DataVersion == 0); 

कक्षा में नए डेटा को जोड़ना, आपको मैन्युअल रूप से DataVersion स्थिरांक को बढ़ाना होगा (यहां अनुशासन आवश्यक है, अफसोस)। लेकिन कंपाइलर तुरंत उन जगहों पर ध्यान देगा, जिन्हें जांचने की जरूरत है। इन सत्यापन बिंदुओं में शामिल होना चाहिए:

• डिजाइनर,
• असाइनमेंट ऑपरेटर (ऑपरेटर =)
• तुलना ऑपरेटरों (==, <, आदि),
• डेटा पढ़ना / लिखना (<<, >> सहित),
• विध्वंसक (यदि यह तुच्छ नहीं है)।

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

लाभ

परिणाम क्या है?
पेशेवरों:

• संकलन चरण में स्वचालित अखंडता की जाँच करें (कभी-कभी, यह डीबगिंग के घंटे और दिन भी बचाता है)।
• ज़ीरो ओवरहेड रन टाइम पर।

विपक्ष:

• अतिरिक्त कोड (यद्यपि अपेक्षाकृत छोटा)।
• आत्म-अनुशासन पर लोड (आपको बस ट्रिगर गिरने की ओर देखने की जरूरत है, और न केवल स्थिर को ठीक करने की)।

मेरे लिए, फायदे पल्ला झुकना, लेकिन आप के लिए?

अपडेटेड कोड हाइलाइटिंग कोड।