C ++ 20 कॉन्ट्रैक्ट प्रोग्रामिंग की कोशिश कर रहा है

C ++ 20 में, अनुबंध प्रोग्रामिंग दिखाई दी है। आज तक, किसी भी कंपाइलर ने अभी तक इस सुविधा के लिए समर्थन लागू नहीं किया है।

लेकिन C ++ 20 से अनुबंध का उपयोग करने की कोशिश करने का एक तरीका है, जैसा कि मानक में वर्णित है।

टीएल, डॉ

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

कॉन्ट्रैक्ट प्रोग्रामिंग के बारे में पहले ही बहुत कुछ लिखा जा चुका है, लेकिन संक्षेप में मैं आपको बताता हूं कि यह क्या है और इसके लिए क्या है।

होर का तर्क

अनुबंधों का प्रतिमान हावर तर्क ( 1 , 2 ) पर आधारित है।

होर तर्क एक एल्गोरिथ्म की शुद्धता को औपचारिक रूप से साबित करने का एक तरीका है।
यह पूर्वधारणा, पोस्टकंडिशन और अपरिवर्तनीय जैसी अवधारणाओं के साथ काम करता है।
व्यावहारिक दृष्टिकोण से, होर के तर्क का उपयोग, सबसे पहले, औपचारिक रूप से एक ऐसे मामले में कार्यक्रम की शुद्धता साबित करने का एक तरीका है जहां त्रुटियां आपदा या जीवन की हानि हो सकती हैं। दूसरे, स्थैतिक विश्लेषण और परीक्षण के साथ-साथ कार्यक्रम की विश्वसनीयता बढ़ाने का एक तरीका।

अनुबंध प्रोग्रामिंग

( 1 , 2 )

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

कभी-कभी उत्पाद विधानसभा में अनुबंधों की भी जांच की जाती है और उनकी गैर-पूर्ति, उदाहरण के लिए, अपवाद की पीढ़ी को जन्म दे सकती है।

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

संविदा के साथ गैर-अनुपालन का परीक्षण चरण में पता लगाया जाना चाहिए और सभी प्रकार के परीक्षणों का अनुपालन करना चाहिए: मॉड्यूलर एकीकरण, आदि।

पहली नज़र में, अनुबंध का उपयोग विकास को अधिक कठिन बनाता है और कोड पठनीयता को कम करता है। वास्तव में, सटीक विपरीत सच है। स्थैतिक टाइपिंग के अनुयायियों को अनुबंधों के लाभों का मूल्यांकन करना सबसे आसान लगेगा, क्योंकि उनका सबसे सरल विकल्प विधियों और कार्यों के हस्ताक्षर में प्रकारों का वर्णन करना है।

तो, अनुबंधों के क्या लाभ हैं:

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

C ++ में अनुबंध प्रोग्रामिंग

अनुबंध प्रोग्रामिंग कई भाषाओं में कार्यान्वित की जाती है। सबसे महत्वपूर्ण उदाहरण एफिल हैं , जहां प्रतिमान पहले लागू किया गया था, और डी , डी अनुबंध में भाषा का हिस्सा हैं।

C ++ में, C ++ 20 मानक से पहले, अनुबंधों का उपयोग अलग-अलग पुस्तकालयों के रूप में किया जा सकता है।

इस दृष्टिकोण के कई नुकसान हैं:

• मैक्रो का उपयोग करते हुए बहुत अनाड़ी वाक्य रचना।
• एकल शैली की कमी।
• कोड का अनुकूलन करने के लिए संकलक द्वारा अनुबंधों का उपयोग करने में असमर्थता।

पुस्तकालय कार्यान्वयन आमतौर पर अच्छे पुराने मुखर और प्रीप्रोसेसर निर्देशों के उपयोग पर आधारित होते हैं जो संकलन ध्वज के लिए जाँच करते हैं।

इस रूप में अनुबंधों का उपयोग करना वास्तव में कोड को बदसूरत और अपठनीय बनाता है। यह एक कारण है कि C ++ में कॉन्ट्रैक्ट्स का उपयोग करना थोड़ा अभ्यास है।

आगे देखते हुए, मैं यह दिखाऊंगा कि अनुबंधों का उपयोग C ++ 20 में कैसे दिखेगा।
और फिर, हम और अधिक विस्तार से इस सब का विश्लेषण करेंगे:

int f(int x, int y) [[ expects: x > 0 ]] // precondition [[ expects: y > 0 ]] // precondition [[ ensures r: r < x + y ]] // postcondition { int z = (x - x%y) / y; [[ assert: z >= 0 ]]; // assertion return z + y; } 

कोशिश

दुर्भाग्य से, इस समय, व्यापक रूप से इस्तेमाल किए गए संकलक में से किसी ने अभी तक अनुबंध समर्थन को लागू नहीं किया है।
लेकिन एक रास्ता है।

यूनिवर्सिडल कार्लोस III डी मैड्रिड के एआरसीओएस अनुसंधान समूह ने क्लैंग ++ कांटा में अनुबंधों के लिए प्रयोगात्मक समर्थन लागू किया।

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

असेंबली निर्देशों को गीथूब भंडार के रीडमी में वर्णित किया गया है
https://github.com/arcosuc3m/clang-contracts

 git clone https://github.com/arcosuc3m/clang-contracts/ mkdir -p clang-contracts/build/ && cd clang-contracts/build/ cmake -G "Unix Makefiles" -DLLVM_USE_LINKER=gold -DBUILD_SHARED_LIBS=ON -DLLVM_USE_SPLIT_DWARF=ON -DLLVM_OPTIMIZED_TABLEGEN=ON ../ make -j8 

मुझे विधानसभा के दौरान कोई समस्या नहीं थी, लेकिन सूत्रों के संकलन में बहुत लंबा समय लगता है।

उदाहरणों को संकलित करने के लिए, आपको स्पष्ट रूप से क्लैंग ++ बाइनरी के लिए पथ निर्दिष्ट करना होगा।
उदाहरण के लिए, यह मेरे लिए कुछ इस तरह दिखता है

 /home/valmat/work/git/clang-contracts/build/bin/clang++ -std=c++2a -build-level=audit -g test.cpp -o test.bin 

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

 git clone https://github.com/valmat/cpp20-contracts-examples/ cd cpp20-contracts-examples make CPP=/path/to/clang++ 

यहाँ /path/to/clang++ आपके प्रयोगात्मक कंपाइलर असेंबली के clang++ बाइनरी का मार्ग है।

कंपाइलर के अलावा, ARCOS अनुसंधान समूह ने अपने कांटे के लिए कंपाइलर एक्सप्लोरर का अपना संस्करण तैयार किया।

C ++ 20 में अनुबंध प्रोग्रामिंग

अब कुछ भी हमें अनुबंध प्रोग्रामिंग द्वारा पेश की जाने वाली संभावनाओं पर शोध करने से रोकता है, और तुरंत इन अवसरों का अभ्यास करने का प्रयास करें।

जैसा कि ऊपर उल्लेख किया गया है, अनुबंध पूर्व शर्त, पोस्टकंडिशन और इनवेरिएंट (स्टेटमेंट) से निर्मित होते हैं।

C ++ 20 में, इसके लिए निम्न सिंटैक्स वाली विशेषताओं का उपयोग किया जाता है

 [[contract-attribute modifier identifier: conditional-expression]] 

जहाँ contract-attribute निम्नलिखित मानों में से एक ले सकती है:
अपेक्षा , सुनिश्चित या मुखर ।

उम्मीदें पूर्व शर्त के लिए उपयोग expects , बयानों के लिए पोस्टकंडिशन और मुखरता ensures ।

conditional-expression एक बूलियन अभिव्यक्ति है जो एक अनुबंध विधेय में मान्य है।
modifier और identifier को छोड़ा जा सकता है।

मुझे एक modifier आवश्यकता क्यों है मैं थोड़ा कम लिखूंगा।

identifier उपयोग केवल ensures करने के लिए किया जाता है और रिटर्न मान का प्रतिनिधित्व करने के लिए उपयोग किया जाता है।

तर्कों में तर्कों की पहुंच है।

फ़ंक्शन द्वारा पोस्टकंडिशन में दिए गए मान तक पहुंच होती है। इसके लिए वाक्य रचना का उपयोग किया जाता है।

 [[ensures return_variable: expr(return_variable)]] 

जहाँ चर के लिए return_variable किसी भी वैध अभिव्यक्ति है।

दूसरे शब्दों में, पूर्वधारणाओं का उद्देश्य फ़ंक्शन द्वारा स्वीकार किए गए तर्कों पर लगाए गए प्रतिबंधों की घोषणा करना है, और फ़ंक्शन द्वारा लौटाए गए मानों पर लगाए गए प्रतिबंधों की घोषणा करना है।

यह माना जाता है कि पूर्वधारणा और पोस्टकंडिशन फ़ंक्शन इंटरफ़ेस का हिस्सा हैं, जबकि स्टेटमेंट इसके कार्यान्वयन का हिस्सा हैं।

फ़ंक्शन निष्पादित होने से तुरंत पहले पूर्व-निर्धारण की भविष्यवाणी की जाती है। कॉलिंग कोड पर नियंत्रण फ़ंक्शन पास होने के तुरंत बाद पोस्टकंडिशन संतुष्ट हैं।

यदि किसी फ़ंक्शन में अपवाद को फेंक दिया जाता है, तो पोस्टकंडिशन की जांच नहीं की जाएगी।
यदि कार्य सामान्य रूप से पूरा होता है, तो पोस्टकंडिशन केवल तभी चेक किए जाते हैं।

यदि अनुबंध में अभिव्यक्ति की जांच करते समय कोई अपवाद हुआ, तो std::terminate() कहा जाएगा।

Preconditions और postconditions को हमेशा फ़ंक्शन बॉडी के बाहर वर्णित किया जाता है और स्थानीय चर तक पहुंच नहीं हो सकती है।

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

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

उदाहरण 1

हम दो प्राथमिकताओं को परिभाषित करते हैं, एक पश्चगामी और एक अपरिवर्तनीय:

 int foo(int x, int y) [[ expects: x > y ]] // precondition #1 [[ expects: y > 0 ]] // precondition #2 [[ ensures r: r < x ]] // postcondition #3 { int z = (x - x%y) / y; [[ assert: z >= 0 ]]; // assertion return z; } int main() { std::cout << foo(117, 20) << std::endl; std::cout << foo(10, 20) << std::endl; // <-- contract violation #1 std::cout << foo(100, -5) << std::endl; // <-- contract violation #2 return 0; } 

उदाहरण 2

एक सार्वजनिक पद्धति का पूर्व शर्त एक संरक्षित या निजी क्षेत्र को संदर्भित नहीं कर सकता है:

 struct X { //protected: int m = 5; public: int foo(int n) [[expects: n < m]] { return n*n; } }; 

अनुबंध की विशेषताओं द्वारा वर्णित अभिव्यक्तियों के भीतर चर के संशोधन की अनुमति नहीं है। अगर यह टूट गया, तो यूबी होगा।

अनुबंधों में वर्णित अभिव्यक्तियों का दुष्प्रभाव नहीं होना चाहिए। हालांकि संकलक इसे सत्यापित कर सकते हैं, लेकिन उन्हें ऐसा करने की आवश्यकता नहीं है। इस आवश्यकता का उल्लंघन अपरिभाषित व्यवहार माना जाता है।

 struct X { int m = 5; int foo(int n) [[ expects: n < m++ ]] // UB: Modifies variable m { int k = n*n; [[ assert: ++k < 100 ]] // UB: Modifies variable k return n*n; } }; 

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

अब मैं सिर्फ इस बात पर ध्यान देता हूं कि सही कार्यक्रम उसी तरह काम करें जैसे कि कोई अनुबंध नहीं था।

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

इसका मतलब यह है कि पूर्ववर्तियों को हमेशा पहले चेक किया जाता है, जैसा कि निम्नलिखित उदाहरण में दिखाया गया है:

 int foo(int n) [[ expects: expr(n) ]] // # 1 [[ ensures r: expr(r) ]] // # 4 [[ expects: expr(n) ]] // # 2 [[ expects: expr(n) ]] // # 3 [[ ensures r: expr(r) ]] // # 5 {...} 

पोस्टकंडिशन में अभिव्यक्तियाँ न केवल फ़ंक्शन द्वारा लौटाए गए मान को संदर्भित कर सकती हैं, बल्कि फ़ंक्शन के तर्कों को भी बता सकती हैं।

 int foo(int &n) [[ ensures: expr(n) ]]; 

इस स्थिति में, आप वापसी मान पहचानकर्ता को छोड़ सकते हैं।

यदि पोस्टकंडिशन फ़ंक्शन के तर्क को संदर्भित करता है, तो यह तर्क फ़ंक्शन से निकास बिंदु पर माना जाता है, और प्रवेश बिंदु पर नहीं, जैसा कि पूर्व शर्त के साथ मामला है।

पोस्टकंडिशन में मूल (फ़ंक्शन एंट्री पॉइंट पर) मूल्य को संदर्भित करने का कोई तरीका नहीं है।

उदाहरण :

 void incr(int &n) [[ expects: 3 == n ]] [[ ensures: 4 == n ]] {++n;} 

अनुबंधों में विधेय स्थानीय चर का उल्लेख कर सकते हैं यदि इन चर का जीवनकाल विधेय गणना समय से मेल खाता है।

उदाहरण के लिए, constexpr कार्यों के लिए, स्थानीय चर को संदर्भित नहीं किया जा सकता है जब तक कि उन्हें संकलन समय पर नहीं जाना जाता है।

उदाहरण :

 int a = 1; constexpr int b = 100; constexpr int foo(int n) [[ expects: a <= n ]] // error: `a` is not constexpr [[ expects: n < b ]] // OK { [[assert: n > 2*a]]; // error: `a` is not constexpr [[assert: n < 2*b]]; // OK return 2*n; } 

फ़ंक्शन पॉइंटर्स के लिए अनुबंध

आप एक फ़ंक्शन पॉइंटर के लिए अनुबंधों को परिभाषित नहीं कर सकते हैं, लेकिन आप एक फ़ंक्शन के पते को असाइन कर सकते हैं जिसके लिए एक फ़ंक्शन पॉइंटर को एक अनुबंध परिभाषित किया गया है।

उदाहरण :

 int foo(int n) [[expects: n < 10]] { return n*n; } int (*pfoo)(int n) = &foo; 

pfoo(100) को कॉल करना अनुबंध का उल्लंघन करेगा।

वंशानुक्रम संविदा

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

C ++ 20 कार्यान्वयन में, यह मामला नहीं है।

सबसे पहले, C ++ 20 में आक्रमणकारी एक कार्यान्वयन का हिस्सा हैं, न कि कोई इंटरफ़ेस। इस कारण से, वे मजबूत और कमजोर दोनों हो सकते हैं। यदि वर्चुअल फ़ंक्शन कार्यान्वयन में कोई assert नहीं है, तो यह विरासत में नहीं मिलेगा।

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

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

उदाहरण :

 struct Base { virtual int foo(int n) [[ expects: n < 10 ]] [[ ensures r: r > 100 ]] { return n*n; } }; struct Derived1 : Base { virtual int foo(int n) override [[ expects: n < 10 ]] [[ ensures r: r > 100 ]] { return n*n*2; } }; struct Derived2 : Base { // Inherits contracts from Base virtual int foo(int n) override { return n*3; } }; 

 virtual int foo(int n) override [[expects: n < 10]] {...} 

 inheritance1.cpp:20:36: error: expected ';' at end of declaration list virtual int foo(int n) override ^ ; 

 virtual int foo(int n) [[expects: n < 10]] override {...} 

अनुबंध संशोधक

अनुबंध विधेयकों की जांच अतिरिक्त प्रसंस्करण लागतों को रोक सकती है।
इसलिए, एक सामान्य अभ्यास विकास में अनुबंधों की जांच करना और बिल्ड बिल्ड का परीक्षण करना और रिलीज़ बिल्ड में उनकी उपेक्षा करना है।

इन उद्देश्यों के लिए, मानक तीन स्तरों के अनुबंध संशोधक प्रदान करता है। संशोधक और संकलक कुंजियों का उपयोग करके, प्रोग्रामर यह नियंत्रित कर सकता है कि कौन से संपर्क विधानसभा में चेक किए गए हैं और जिन्हें अनदेखा किया गया है।

• default - इस संशोधक का उपयोग डिफ़ॉल्ट रूप से किया जाता है। यह माना जाता है कि इस संशोधक के साथ एक अभिव्यक्ति के निष्पादन की पुष्टि करने की कम्प्यूटेशनल लागत फ़ंक्शन की गणना की लागत की तुलना में छोटी है।
• audit - यह संशोधक मानता है कि किसी फ़ंक्शन के कम्प्यूटिंग की तुलना में अभिव्यक्ति के निष्पादन की पुष्टि करने की कम्प्यूटेशनल लागत महत्वपूर्ण है।
• axiom - यदि अभिव्यक्ति घोषणात्मक है तो इस संशोधक का उपयोग किया जाता है। रनटाइम पर चेक नहीं किया गया। स्थैतिक विश्लेषक और एक कंपाइलर ऑप्टिमाइज़र द्वारा उपयोग के लिए एक फ़ंक्शन के इंटरफ़ेस का दस्तावेजीकरण करने के लिए कार्य करता है। axiom संशोधक के साथ अभिव्यक्तियाँ कभी भी रनटाइम पर मूल्यांकन नहीं की axiom ।

उदाहरण

 [[expects: expr]] //  default [[expects default: expr]] //  default [[expects axiom : expr]] // Run-time    [[expects audit : expr]] //    

संशोधक का उपयोग करके, आप यह निर्धारित कर सकते हैं कि आपकी असेंबली के कौन से संस्करणों का उपयोग किया जाएगा और कौन सा अक्षम होगा।

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

संकलक के विवेक पर, एक्सिओम के रूप में चिह्नित अभिव्यक्तियों के axiom को सक्षम करने के लिए सुविधाएं प्रदान की जा सकती हैं।

हमारे मामले में, यह एक संकलक विकल्प है

 -axiom-mode=<mode> 

-axiom-mode=on axiom मोड -axiom-mode=on चालू करता है और, तदनुसार, पहचानकर्ता axiom साथ दावों का सत्यापन बंद कर देता है ,

-axiom-mode=off स्वयंसिद्ध मोड बंद करता है और तदनुसार, पहचानकर्ता axiom साथ बयानों के सत्यापन को सक्षम करता है।

उदाहरण :

 int foo(int n) [[expects axiom: n < 10]] { return n*n; } 

एक कार्यक्रम को सत्यापन के तीन विभिन्न स्तरों के साथ संकलित किया जा सकता है:

• off अनुबंधों में सभी अभिव्यक्ति जांच बंद off देता है
• default केवल default संशोधक के साथ अभिव्यक्ति की जाँच की जाती है
• audit उन्नत मोड जब सभी चेक default और audit संशोधक के साथ किए जाते हैं

कंपाइलर डेवलपर्स के विवेक पर सत्यापन स्तर की स्थापना को लागू करने के लिए बिल्कुल सही कैसे है।

हमारे मामले में, इसके लिए संकलक विकल्प का उपयोग किया जाता है

 -build-level=<off|default|audit> 

डिफ़ॉल्ट है -build-level=default

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

मैं अगले खंड तक विधानसभा स्तरों के आवेदन के उदाहरणों को स्थगित कर दूंगा, जहां उन्हें दृश्य बनाया जा सकता है।

अनुबंध के उल्लंघन की अवरोधन

अनुबंध के उल्लंघन के मामले में कार्यक्रम किस विकल्प पर जा रहा है, इसके आधार पर अलग-अलग व्यवहार परिदृश्य हो सकते हैं।

डिफ़ॉल्ट रूप से, अनुबंध का एक उल्लंघन कार्यक्रम को दुर्घटनाग्रस्त कर देता है, जिसे std::terminate() । लेकिन प्रोग्रामर अपने स्वयं के हैंडलर प्रदान करके और संकलक को इंगित करके इस व्यवहार को ओवरराइड कर सकता है कि अनुबंध के उल्लंघन के बाद कार्यक्रम को जारी रखना आवश्यक है।

संकलन पर, आप उल्लंघन हैंडलर स्थापित कर सकते हैं, जिसे अनुबंध का उल्लंघन होने पर कहा जाता है।

हैंडलर की स्थापना को लागू करने का तरीका संकलक के रचनाकारों के विवेक पर है।

हमारे मामले में, यह

 -contract-violation-handler=<violation_handler> 

प्रोसेसर हस्ताक्षर होना चाहिए

 void(const std::contract_violation& info) 

या

 void(const std::contract_violation& info) noexcept 

std::contract_violation निम्नलिखित परिभाषा के बराबर है:

 struct contract_violation { uint_least32_t line_number() const noexcept; std::string_view file_name() const noexcept; std::string_view function_name() const noexcept; std::string_view comment() const noexcept; std::string_view assertion_level() const noexcept; }; 

इस प्रकार, हैंडलर आपको इस बात के बारे में काफी व्यापक जानकारी प्राप्त करने की अनुमति देता है कि अनुबंध शर्तों का उल्लंघन कहां और किन परिस्थितियों में हुआ।

यदि उल्लंघन हैंडलर हैंडलर निर्दिष्ट किया जाता है, तो अनुबंध उल्लंघन के मामले में, डिफ़ॉल्ट रूप से, std::abort() इसके निष्पादन के तुरंत बाद बुलाया जाएगा (हैंडलर निर्दिष्ट किए बिना, std::terminate() कहा जाएगा)।

मानक मानता है कि संकलक उपकरण प्रदान करते हैं जो प्रोग्रामर को अनुबंध के उल्लंघन के बाद एक कार्यक्रम को जारी रखने की अनुमति देते हैं।

इन उपकरणों को लागू करने का तरीका संकलक डेवलपर्स के विवेक पर छोड़ दिया गया है।
हमारे मामले में, यह एक संकलक विकल्प है

 -fcontinue-after-violation 

-fcontinue-after-violation और -contract-violation-handler एक-दूसरे से स्वतंत्र रूप से सेट किए जा सकते हैं। उदाहरण के लिए, आप -fcontinue-after-violation सेट कर सकते हैं, लेकिन सेट -fcontinue-after-violation -contract-violation-handler । बाद के मामले में, अनुबंध के उल्लंघन के बाद, कार्यक्रम बस काम करना जारी रखेगा।

अनुबंध के उल्लंघन के बाद कार्यक्रम को जारी रखने की क्षमता मानक द्वारा निर्दिष्ट की गई है, लेकिन इस सुविधा के साथ देखभाल की जानी चाहिए।

तकनीकी रूप से, अनुबंध के उल्लंघन के बाद एक कार्यक्रम के व्यवहार को परिभाषित नहीं किया जाता है, भले ही प्रोग्रामर ने स्पष्ट रूप से संकेत दिया हो कि कार्यक्रम को काम करना जारी रखना चाहिए।

यह संकलक अनुबंध निष्पादन के आधार पर निम्न-स्तरीय अनुकूलन करने में सक्षम होने के कारण है।

आदर्श रूप से, यदि अनुबंध का उल्लंघन होता है, तो आपको जल्द से जल्द नैदानिक ​​जानकारी दर्ज करने और कार्यक्रम को समाप्त करने की आवश्यकता है। आपको यह समझने की आवश्यकता है कि आप उल्लंघन के बाद कार्यक्रम को काम करने की अनुमति देकर क्या कर रहे हैं।

अपने हैंडलर को परिभाषित करें और अनुबंध के उल्लंघन को रोकने के लिए इसका उपयोग करें

 void violation_handler(const std::contract_violation& info) { std::cerr << "line_number : " << info.line_number() << std::endl; std::cerr << "file_name : " << info.file_name() << std::endl; std::cerr << "function_name : " << info.function_name() << std::endl; std::cerr << "comment : " << info.comment() << std::endl; std::cerr << "assertion_level : " << info.assertion_level() << std::endl; } 

और अनुबंध उल्लंघन के एक उदाहरण पर विचार करें:

 #include "violation_handler.h" int foo(int n) [[expects: n < 10]] { return n*n; } int main() { foo(100); // <-- contract violation return 0; } 

हम विकल्प -contract-violation-handler=violation_handler -fcontinue-after-violation -contract-violation-handler=violation_handler -fcontinue-after-violation और -fcontinue-after-violation और रन के साथ कार्यक्रम को संकलित करते हैं

 $ bin/example8-handling.bin line_number : 4 file_name : example8-handling.cpp function_name : foo comment : n < 10 assertion_level : default 

अब हम विभिन्न विधानसभा स्तरों और अनुबंध मोड पर अनुबंध के उल्लंघन के मामले में कार्यक्रम के व्यवहार को प्रदर्शित करने वाले उदाहरण दे सकते हैं।

निम्नलिखित उदाहरण पर विचार करें:

 #include "violation_handler.h" int foo(int n) [[ expects axiom : n < 100 ]] [[ expects default : n < 200 ]] [[ expects audit : n < 300 ]] { return 2 * n; } int main() { foo(350); // audit foo(250); // default return 0; } 

यदि आप इसे -build-level=off विकल्प के साथ -build-level=off , तो उम्मीद के मुताबिक, अनुबंधों की जाँच नहीं की जाएगी।

default स्तर के साथ इकट्ठा करना (विकल्प -build-level=default ), हम निम्नलिखित आउटपुट प्राप्त करते हैं:

 $ bin/example9-default.bin line_number : 5 file_name : example9.cpp function_name : foo comment : n < 200 assertion_level : default line_number : 5 file_name : example9.cpp function_name : foo comment : n < 200 assertion_level : default 

और audit स्तर वाली विधानसभा देगी:

  $ bin/example9-audit.bin line_number : 5 file_name : example9.cpp function_name : foo comment : n < 200 assertion_level : default line_number : 6 file_name : example9.cpp function_name : foo comment : n < 300 assertion_level : audit line_number : 5 file_name : example9.cpp function_name : foo comment : n < 200 assertion_level : default 

टिप्पणी

violation_handler अपवाद फेंक सकते हैं। इस मामले में, आप प्रोग्राम को कॉन्फ़िगर कर सकते हैं ताकि अनुबंध का उल्लंघन अपवाद के फेंकने के लिए हो।

यदि वह फ़ंक्शन जिसके लिए कॉन्ट्रैक्ट्स का वर्णन किया गया है, को noexcept के रूप में चिह्नित किया noexcept और जब कॉन्ट्रैक्ट noexcept को चेक किया जाता है, जो एक अपवाद फेंकता है, तो std::terminate() कहा जाएगा।

उदाहरण

 void violation_handler(const std::contract_violation&) { throw std::exception(); } int foo(int n) noexcept [[ expects: n > 0 ]] { return n*n; } int main() { foo(0); // <-- std::terminate() when violation handler throws an exception return 0; } 

यदि ध्वज संकलक को दिया जाता है: अनुबंध तोड़ने के बाद प्रोग्राम को निष्पादित करना जारी न रखें ( continuation mode=off ), लेकिन उल्लंघन हैंडलर एक अपवाद फेंकता है, तो std::terminate() मजबूर हो जाएगा।

निष्कर्ष

कॉन्ट्रैक्ट नॉन-इंट्रसिव रनटाइम चेक से संबंधित होते हैं। वे जारी सॉफ्टवेयर की गुणवत्ता सुनिश्चित करने में बहुत महत्वपूर्ण भूमिका निभाते हैं।

C ++ का उपयोग बहुत व्यापक रूप से किया जाता है। और निश्चित रूप से अनुबंधों के विनिर्देश के लिए पर्याप्त संख्या में दावे होंगे। मेरे व्यक्तिपरक राय में, कार्यान्वयन काफी सुविधाजनक और दृश्य हो गया।

C ++ 20 अनुबंध हमारे कार्यक्रमों को और अधिक विश्वसनीय, तेज और समझने योग्य बनाएंगे। मैं कंपाइलरों में उनके कार्यान्वयन के लिए तत्पर हूं।

पुनश्च
पीएम में, वे मुझे बताते हैं कि शायद मानक expects के अंतिम संस्करण में और ensures जाता है कि क्रमशः pre और post बदल दिया जाएगा।