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

सामग्री की तालिका

प्रमोनिटस, प्रामुनीटस।
पूर्वाभास का अर्थ है सशस्त्र। (अक्षां।)

परिचय

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

1. प्रकार

1.1। सशर्त निर्देश और ऑपरेटर

सी के साथ संगतता की आवश्यकता इस तथ्य की ओर ले जाती है कि if(...) और इस तरह के बयान में, आप किसी भी संख्यात्मक अभिव्यक्ति या सूचक को स्थानापन्न कर सकते हैं, और न कि केवल bool तरह अभिव्यक्ति। समस्या को अंकगणितीय अभिव्यक्तियों में bool से दूसरे में अंतर्निहित रूपांतरण और कुछ ऑपरेटरों की प्राथमिकता से जटिल किया गया है। यह, उदाहरण के लिए, निम्न त्रुटियों की ओर जाता है:

if(a=b) जब सही ढंग से if(a==b) ,
if(a<x<b) , जब सही ढंग से if(a<x && x<b) ,
if(a&x==0) , जब सही ढंग से if((a&x)==0) ,
if(Foo) सही ढंग से if(Foo()) ,
if(arr) सही ढंग से if(arr[0]) ,
if(strcmp(s,r)) जब सही हो if(strcmp(s,r)==0) ।

इन त्रुटियों में से कुछ एक संकलक चेतावनी का कारण बनती हैं, लेकिन एक त्रुटि नहीं। कोड विश्लेषक भी कभी-कभी मदद कर सकते हैं। C # में, ऐसी त्रुटियां लगभग असंभव हैं, if(...) और जैसे कि एक bool प्रकार की आवश्यकता होती है, तो आप अंकगणितीय अभिव्यक्तियों में bool और संख्यात्मक प्रकारों को नहीं मिला सकते हैं।

कैसे लड़ें:

• चेतावनियों के बिना कार्यक्रम। दुर्भाग्य से, यह हमेशा मदद नहीं करता है, ऊपर वर्णित कुछ त्रुटियां चेतावनी नहीं देती हैं।
• स्टैटिक कोड एनालाइजर का उपयोग करें।
• पुराने जमाने की रिसेप्शन तकनीक: जब एक स्थिरांक के साथ तुलना की जाती है, तो इसे बाईं ओर रखें, उदाहरण के लिए if(MAX_PATH==x) । यह सुंदर कोंडो दिखता है (और यहां तक ​​कि इसका अपना नाम भी है - "योदा संकेतन"), और माना जाने वाले मामलों की एक छोटी संख्या में मदद करता है।
• यथासंभव व्यापक रूप से const क्वालिफायर का उपयोग करें। फिर, यह हमेशा मदद नहीं करता है।
• अपने आप को सही तार्किक अभिव्यक्ति लिखने के लिए अनुकूलित करें: if(x!=0) बजाय if(x) । (हालांकि आप यहां ऑपरेटर प्राथमिकताओं के जाल में पड़ सकते हैं, तीसरा उदाहरण देखें।)
• अत्यंत चौकस रहो।

1.2। सम्यक रूपांतरण

C ++ का तात्पर्य दृढ़ता से टाइप की जाने वाली भाषाओं से है, लेकिन कोड को कम करने के लिए निहित प्रकार के रूपांतरणों का व्यापक रूप से उपयोग किया जाता है। ये निहितार्थ रूपांतरण कुछ मामलों में त्रुटियों को जन्म दे सकते हैं।

सबसे कष्टप्रद निहितार्थ रूपांतरण एक संख्यात्मक प्रकार या सूचक से bool और bool से int तक के रूपांतरण हैं। यह इन परिवर्तनों (सी के साथ संगतता के लिए आवश्यक) है जो धारा 1.1 में वर्णित समस्याओं का कारण बनते हैं। अनुमानित रूपांतरण जो संभावित रूप से संख्यात्मक डेटा (रूपांतरण को कम करने) की सटीकता में कमी का कारण बनते हैं, उदाहरण के लिए, double से int हमेशा उपयुक्त नहीं होते हैं। कई मामलों में, कंपाइलर एक चेतावनी उत्पन्न करता है (विशेषकर जब संख्यात्मक डेटा की सटीकता का नुकसान हो सकता है), लेकिन एक चेतावनी एक त्रुटि नहीं है। C # में, संख्यात्मक प्रकार और bool बीच रूपांतरण निषिद्ध है (यहां तक ​​कि स्पष्ट), और रूपांतरण जो संभावित रूप से संख्यात्मक डेटा में परिशुद्धता के नुकसान का कारण बनते हैं, लगभग हमेशा एक त्रुटि होती है।

प्रोग्रामर अन्य निहित रूपांतरण जोड़ सकता है: (1) explicit कीवर्ड के बिना एक पैरामीटर के साथ एक कंस्ट्रक्टर को परिभाषित करना; (2) एक प्रकार के रूपांतरण ऑपरेटर की परिभाषा। ये परिवर्तन मजबूत टाइपिंग सिद्धांतों के आधार पर अतिरिक्त सुरक्षा अंतराल को तोड़ते हैं।

C # में, अंतर्निहित अंतर्निहित रूपांतरणों की संख्या बहुत कम है, implicit कीवर्ड का उपयोग करके कस्टम अंतर्निहित रूपांतरणों को घोषित किया जाना चाहिए।

कैसे लड़ें:

• चेतावनियों के बिना कार्यक्रम।
• ऊपर वर्णित डिजाइनों के बारे में बहुत सावधान रहें, अत्यधिक आवश्यकता के बिना उनका उपयोग न करें।

2. नाम का संकल्प

2.1। नेस्टेड स्कोप्स में चर को छिपाते हुए

C ++ में, निम्न नियम लागू होता है। चलो

 //   {    int x;    // ... //  ,       {        int x;        // ...    } } 

सी ++ नियमों के अनुसार, में घोषित चर में घोषित चर छुपाता है पहले डिक्लेरेशन x ब्लॉक में होना जरूरी नहीं है: यह एक क्लास या ग्लोबल वैरिएबल का सदस्य हो सकता है, इसे सिर्फ ब्लॉक में दिखना होगा

अब उस स्थिति की कल्पना करें जब आपको निम्न कोड को फिर से भरना होगा

 //   {    int x;    // ... //  ,       {    // -         } } 

गलती से, परिवर्तन किए जाते हैं:

 //   {    //  , :    int x;    // -         // ...    //  :    // -      } 

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

कैसे लड़ें:

• संभव सबसे कम दायरे में चरों की घोषणा करें।
• लंबे और गहरे नेस्टेड ब्लॉक न लिखें।
• अलग-अलग दायरे के पहचानकर्ताओं को अलग पहचानने के लिए कोडिंग सम्मेलनों का उपयोग करें।
• अत्यंत चौकस रहो।

2.2। कार्य अधिभार

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

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

नेस्ट दृश्यता क्षेत्रों में अधिभार को हल करने के लिए उम्मीदवारों के लिए खोज एल्गोरिदम द्वारा समस्याएं पैदा की जा सकती हैं। यदि संकलक को मौजूदा दायरे में कोई उम्मीदवार मिला है, तो आगे की खोज समाप्त हो गई है। यदि पाए गए उम्मीदवार उपयुक्त नहीं हैं, तो परस्पर विरोधी, हटाए गए या अप्राप्य हैं, एक त्रुटि उत्पन्न होती है, लेकिन आगे की खोज का प्रयास नहीं किया जाता है। और केवल अगर वर्तमान दायरे में कोई उम्मीदवार नहीं हैं, तो खोज अगले, व्यापक दायरे में जाती है। नाम छिपाने का तंत्र काम करता है, जो कि धारा 2.1 में चर्चा के समान है, देखें [देवरसस्ट]।

ओवरलोडिंग फ़ंक्शन कोड की पठनीयता को कम कर सकता है, जिसका अर्थ है त्रुटियों को भड़काना।

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

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

C # फ़ंक्शन ओवरलोडिंग का भी समर्थन करता है, लेकिन ओवरलोड को हल करने के नियम थोड़े अलग हैं।

कैसे लड़ें:

• फ़ंक्शन ओवरलोडिंग का दुरुपयोग न करें, साथ ही डिफ़ॉल्ट मापदंडों के साथ फ़ंक्शन को डिज़ाइन करना।
• यदि फ़ंक्शन अतिभारित हैं, तो ऐसे हस्ताक्षरों का उपयोग करें जो ओवरलोड को हल करते समय संदेह में नहीं हैं।
• नेस्टेड स्कोप में एक ही नाम के कार्यों की घोषणा न करें।
• यह मत भूलो कि C ++ 11 में दिखाई देने वाले दूरस्थ फ़ंक्शंस ( =delete ) के तंत्र का उपयोग कुछ अधिभार विकल्पों पर प्रतिबंध लगाने के लिए किया जा सकता है।

3. कंस्ट्रक्टर्स, डिस्ट्रक्टर्स, इनिशियलाइज़ेशन, डिलीशन

3.1। संकलक द्वारा उत्पन्न कक्षा सदस्य कार्य

यदि प्रोग्रामर ने निम्न सूची में से क्लास के सदस्य कार्यों को परिभाषित नहीं किया है - डिफ़ॉल्ट कंस्ट्रक्टर, कॉपी कंस्ट्रक्टर, कॉपी असाइनमेंट ऑपरेटर, डिस्ट्रक्टर - तो कंपाइलर उसके लिए ऐसा कर सकता है। C ++ 11 ने इस सूची में मूव कंस्ट्रक्टर और मूव असाइनमेंट ऑपरेटर को जोड़ा। इन सदस्य कार्यों को विशेष सदस्य कार्य कहा जाता है। वे केवल तभी उत्पन्न होते हैं जब उनका उपयोग किया जाता है, और प्रत्येक फ़ंक्शन के लिए विशिष्ट अतिरिक्त शर्तें पूरी होती हैं। हम इस तथ्य पर ध्यान आकर्षित करते हैं कि यह उपयोग काफी छिपा हुआ हो सकता है (उदाहरण के लिए, जब विरासत को लागू करते हुए)। यदि आवश्यक फ़ंक्शन उत्पन्न नहीं किया जा सकता है, तो एक त्रुटि उत्पन्न होती है। (रिलोकेशन ऑपरेशंस के अपवाद के साथ, उन्हें कॉपी ऑपरेशंस द्वारा बदल दिया जाता है।) कंपाइलर द्वारा बनाए गए सदस्य फ़ंक्शन सार्वजनिक और एम्बेड करने योग्य होते हैं। विशेष सदस्य कार्यों पर विवरण [Meyers2] में पाया जा सकता है।

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

प्रोग्रामर विशेष सदस्य कार्यों की पीढ़ी को प्रतिबंधित कर सकता है, C ++ 11 में घोषणा करते समय "=delete" निर्माण का उपयोग करना आवश्यक है, C ++ 98 में संबंधित सदस्य फ़ंक्शन को निजी घोषित करें और परिभाषित न करें।

यदि प्रोग्रामर संकलक द्वारा उत्पन्न सदस्य कार्यों के साथ सहज है, तो C ++ 11 में वह इसे स्पष्ट रूप से इंगित कर सकता है, न कि केवल घोषणा को छोड़ दें। ऐसा करने के लिए, आपको घोषणा करते समय "=default" निर्माण का उपयोग करना चाहिए, जबकि कोड बेहतर पढ़ा जाता है और अतिरिक्त स्तर एक्सेस स्तर के प्रबंधन से संबंधित दिखाई देते हैं।

C # में, कंपाइलर एक डिफॉल्ट कंस्ट्रक्टर जनरेट कर सकता है, आमतौर पर इससे कोई समस्या नहीं होती है।

कैसे लड़ें:

• संकलक विशेष सदस्य कार्यों को उत्पन्न करने पर नियंत्रण रखें। यदि आवश्यक हो, तो उन्हें स्वयं लागू करें या निषिद्ध करें।

3.2। Uninitialized चर

कंस्ट्रक्टर्स और डिस्ट्रक्टर्स को C ++ ऑब्जेक्ट मॉडल के प्रमुख तत्व कहा जा सकता है। ऑब्जेक्ट बनाते समय, कंस्ट्रक्टर को बुलाया जाना चाहिए, और हटाते समय, विध्वंसक को कहा जाता है। लेकिन सी के साथ संगतता समस्याओं ने कुछ अपवादों को मजबूर किया है, और इस अपवाद को तुच्छ प्रकार कहा जाता है। वे निर्माणकर्ता और विध्वंसक के अनिवार्य कॉल के बिना, चर प्रकार के sichny प्रकार और syshny जीवन चक्र का अनुकरण करने के लिए पेश किए जाते हैं। C कोड, यदि C ++ में संकलित और निष्पादित किया गया है, तो सी की तरह काम करना चाहिए। सामान्य प्रकारों में संख्यात्मक प्रकार, संकेत, गणना, साथ ही वर्ग, संरचनाएं, संघ और सरणियाँ शामिल हैं, जिसमें तुच्छ प्रकार शामिल हैं। कक्षाओं और संरचनाओं को कुछ अतिरिक्त शर्तों को पूरा करना चाहिए: कस्टम निर्माता, विध्वंसक, प्रतिलिपि, आभासी कार्यों की अनुपस्थिति। एक तुच्छ वर्ग के लिए, कंपाइलर एक डिफ़ॉल्ट कंस्ट्रक्टर और एक विध्वंसक उत्पन्न कर सकता है। डिफ़ॉल्ट निर्माता ऑब्जेक्ट को शून्य करता है, विध्वंसक कुछ भी नहीं करता है। लेकिन यह कंस्ट्रक्टर जनरेट किया जाएगा और इसका उपयोग तभी किया जाएगा जब इसे वेरिएबल इनिशियलाइज़ होने पर स्पष्ट रूप से कॉल किया जाएगा। यदि आप स्पष्ट आरंभीकरण के कुछ प्रकार का उपयोग नहीं करते हैं, तो एक तुच्छ प्रकार का एक चर अनैतिक रूप से बदल दिया जाएगा। इनिशियलाइज़ सिंटैक्स, वेरिएबल डिक्लेरेशन के प्रकार और संदर्भ पर निर्भर करता है। घोषित होने पर स्थैतिक और स्थानीय चर आरंभ होते हैं। एक वर्ग के लिए, तत्काल आधार वर्ग और गैर-स्थिर वर्ग के सदस्यों को प्रारंभिक आरंभीकरण सूची में आरंभ किया जाता है। (C ++ 11 आपको घोषणा करते समय गैर-स्थिर वर्ग के सदस्यों को इनिशियलाइज़ करने की अनुमति देता है। बाद में देखें।) डायनामिक ऑब्जेक्ट्स के लिए, एक्सप्रेशन new T() डिफ़ॉल्ट कंस्ट्रक्टर द्वारा इनिशियलाइज़ किए गए ऑब्जेक्ट को बनाता है, लेकिन तुच्छ प्रकारों के लिए new T एक अनिनिर्धारित ऑब्जेक्ट बनाता है। एक तुच्छ प्रकार, new T[N] एक गतिशील सरणी बनाते समय, इसके तत्व हमेशा असिंचित रहेंगे। यदि std::vector<T> का एक उदाहरण बनाया या विस्तारित किया गया है और तत्वों के स्पष्ट आरंभ के लिए पैरामीटर प्रदान नहीं किए गए हैं, तो उन्हें डिफ़ॉल्ट कंस्ट्रक्टर को कॉल करने की गारंटी दी जाती है। C ++ 11 एक नया इनिशियलाइज़ेशन सिंटैक्स प्रस्तुत करता है - घुंघराले ब्रेसिज़ का उपयोग करते हुए। कोष्ठक की एक खाली जोड़ी का अर्थ है डिफ़ॉल्ट निर्माणकर्ता का उपयोग करना। इस तरह की इनिशियलाइज़ेशन हर जगह जहाँ पारंपरिक इनिशियलाइज़ेशन का उपयोग किया जाता है, इसके अलावा यह घोषणा करते समय कक्षा के गैर-स्थैतिक सदस्यों को इनिशियलाइज़ करना संभव हो गया, जो कि इनिशियलाइज़ेशन को कंस्ट्रक्टर इनिशियलाइज़ेशन लिस्ट में बदल देता है।

एक uninitialized चर को निम्नानुसार संरचित किया जाता है: यदि इसे namespace (वैश्विक रूप से) में परिभाषित किया गया है, तो इसमें सभी बिट्स शून्य होंगे, यदि यह स्थानीय या गतिशील रूप से बनाया गया है, तो यह बिट्स का एक यादृच्छिक सेट प्राप्त करेगा। यह स्पष्ट है कि इस तरह के एक चर का उपयोग कार्यक्रम के अप्रत्याशित व्यवहार को जन्म दे सकता है।

सच है, प्रगति अभी भी खड़ा नहीं है, आधुनिक संकलक, कुछ मामलों में, असिंचित चर का पता लगाते हैं और एक त्रुटि फेंकते हैं। Uninitialized कोड एनालाइज़र बेहतर का पता लगाते हैं।

C ++ 11 मानक पुस्तकालय में प्रकार के गुण (हेडर फ़ाइल <type_traits> ) नामक टेम्पलेट हैं। उनमें से एक आपको यह निर्धारित करने की अनुमति देता है कि क्या प्रकार तुच्छ है। अभिव्यक्ति std::is_trivial<>::value true यदि T तुच्छ प्रकार है और false है।

Sysylic संरचनाओं को अक्सर प्लेन ओल्ड डेटा (POD) भी कहा जाता है। हम मान सकते हैं कि POD और "तुच्छ प्रकार" लगभग समान शब्द हैं।

C # में, uninitialized चर एक त्रुटि का कारण बनते हैं; इसे कंपाइलर द्वारा नियंत्रित किया जाता है। यदि स्पष्ट आरंभीकरण नहीं किया जाता है, तो संदर्भ प्रकार की वस्तुओं के फ़ील्ड्स को डिफ़ॉल्ट रूप से प्रारंभ किया जाता है। एक महत्वपूर्ण प्रकार की वस्तुओं के फ़ील्ड्स को या तो सभी डिफ़ॉल्ट रूप से प्रारंभ किया जाता है, या सभी को स्पष्ट रूप से प्रारंभ किया जाना चाहिए।

कैसे लड़ें:

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

3.3। बेस क्लास और नॉन-स्टेटिक क्लास सदस्यों के लिए प्रारंभिक प्रक्रिया

क्लास कंस्ट्रक्टर को लागू करते समय, तत्काल बेस क्लास और नॉन-स्टैटिक क्लास मेंबर को इनिशियलाइज़ किया जाता है। आरंभीकरण क्रम मानक द्वारा निर्धारित किया जाता है: पहला, आधार वर्गों को उस क्रम में जिसमें उन्हें आधार वर्गों की सूची में घोषित किया जाता है, फिर घोषणा क्रम में कक्षा के गैर-स्थैतिक सदस्य। यदि आवश्यक हो, तो आधार वर्गों और गैर-स्थैतिक सदस्यों की स्पष्ट प्रारंभिक रचना, निर्माण आरंभीकरण सूची का उपयोग करती है। दुर्भाग्यवश, इस सूची की वस्तुओं को उस क्रम में होना आवश्यक नहीं है जिसमें आरंभीकरण होता है। इसे ध्यान में रखा जाना चाहिए, यदि आरंभीकरण के दौरान, सूची आइटम अन्य सूची आइटमों के संदर्भ का उपयोग करते हैं। त्रुटि पर, लिंक एक ऐसी वस्तु के लिए हो सकता है जिसे अभी तक आरंभीकृत नहीं किया गया है। सी ++ 11 आपको घोषणा करते समय गैर-स्थिर वर्ग के सदस्यों को शुरू करने की अनुमति देता है (घुंघराले ब्रेसिज़ का उपयोग करके)। इस मामले में, उन्हें निर्माणकर्ता आरंभीकरण सूची में आरंभ करने की आवश्यकता नहीं है और समस्या को आंशिक रूप से हटा दिया गया है।

C # में, एक ऑब्जेक्ट को इस प्रकार से इनिशियलाइज़ किया जाता है: पहले फ़ील्ड्स को इनिशियलाइज़ किया जाता है, बेस सबोबिज से लेकर आखिरी व्युत्पन्न तक, फिर कंस्ट्रक्टर्स को उसी क्रम में बुलाया जाता है। वर्णित समस्या उत्पन्न नहीं होती है।

कैसे लड़ें:

• घोषणा क्रम में निर्माण आरंभीकरण सूची को बनाए रखें।
• आधार वर्गों और वर्ग के सदस्यों के आरंभ को स्वतंत्र बनाने का प्रयास करें।
• घोषणा करते समय गैर-स्थैतिक सदस्यों के आरंभ का उपयोग करें।

3.4। स्टैटिक क्लास के सदस्यों और वैश्विक चर के लिए प्रारंभिक प्रक्रिया

स्थैतिक वर्ग के सदस्यों, साथ ही विभिन्न संकलनों इकाइयों (फाइलों) में स्कोप namespace (वैश्विक रूप से) में परिभाषित चर, कार्यान्वयन द्वारा निर्धारित क्रम में आरंभिक हैं। इसे ध्यान में रखा जाना चाहिए यदि आरंभीकरण के दौरान ऐसे चर एक दूसरे के संदर्भ का उपयोग करते हैं। लिंक एक असिंचित चर के लिए हो सकता है।

कैसे लड़ें:

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

3.5। नाशवानों में अपवाद

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

कैसे लड़ें:

• विध्वंसक में अपवाद फेंकने से बचें।

3.6। गतिशील वस्तुओं और सरणियों को हटाना

यदि किसी प्रकार T एक गतिशील ऑब्जेक्ट T

 T* pt = new T(/* ... */); 

फिर इसे हटाए गए ऑपरेटर के साथ हटा दिया जाता है

 delete pt; 

यदि एक गतिशील सरणी बनाई जाती है

 T* pt = new T[N]; 

तब इसे हटा दिया जाता है delete[] ऑपरेटर के साथ

 delete[] pt; 

यदि आप इस नियम का पालन नहीं करते हैं, तो आप अपरिभाषित व्यवहार प्राप्त कर सकते हैं, अर्थात, कुछ भी हो सकता है: एक स्मृति रिसाव, दुर्घटना, आदि। विवरण के लिए देखें [Meyers1]।

कैसे लड़ें:

• सही delete फॉर्म का उपयोग करें।

3.7। वर्ग घोषणा अपूर्ण होने पर हटाना

delete ऑपरेटर की सर्वव्यापीता कुछ समस्याएं पैदा कर सकती है; इसे टाइप void* पॉइंटर पर लगाया जा सकता है या एक पॉइंटर को पॉइंटर में अधूरा (प्रीमेप्टिव) घोषित किया जा सकता है। delete ऑपरेटर को एक पॉइंटर से एक कक्षा में लागू किया जाता है एक दो-चरण ऑपरेशन होता है, पहले, विध्वंसक को बुलाया जाता है, फिर मेमोरी को मुक्त किया जाता है।यदि ऑपरेटर को deleteएक अधूरा घोषणा के साथ एक कक्षा में पॉइंटर पर लागू किया जाता है, तो कोई त्रुटि नहीं होती है, संकलक बस कॉल को विध्वंसक (हालांकि एक चेतावनी जारी की जाती है) को छोड़ देता है। एक उदाहरण पर विचार करें:

 class X; //   X* CreateX(); void Foo() {    X* p = CreateX();    delete p; } 

warning C4150: deletion of pointer to incomplete type 'X'; no destructor called

यदि कोई कार्यान्वयन है Xऔर CreateX()फिर, कोड संकलित किया जाता है, यदि यह CreateX()ऑपरेटर द्वारा बनाई गई किसी वस्तु के लिए एक संकेतक लौटाता है new, तो कॉल Foo()सफलतापूर्वक निष्पादित किया जाता है, विध्वंसक नहीं कहा जाता है। यह स्पष्ट है कि इससे संसाधनों की कमी हो सकती है, इसलिए एक बार फिर चेतावनी के बारे में सावधान रहने की आवश्यकता है।

, -. , . , , , , . [Meyers2].

:

• .
• .
• .

4. ,

4.1।

++ , . . . , 1.1.

यहाँ एक उदाहरण है:

 std::out<<c?x:y; 

 (std::out<<c)?x:y; 

 std::out<<(c?x:y); 

, , .

. << ?: std::out void* . ++ , . -, , . ?: . , ( ).

: x&f==0 x&(f==0) , (x&f)==0 , , , . - , , , , .

. / . / , /, . , x/4+1 x>>2+1 , x>>(2+1) , (x>>2)+1 , .

C# , C++, , - .

:

• , . , , .

4.2।

++ , . . , , . 4.1. — + += . . , : , (), && , || । , (-), (short-circuit evaluation semantics), , . & ( ). & , .. .

, - (-) , . .

- , , . . [Dewhurst].

C# , , , .

:

• .
• .

4.3.

++ , . ( : , (), && , || , ?: .) , , , . :

 int x=0; int y=(++x*2)+(++x*3); 

y .

, . .

 class X; class Y; void Foo(std::shared_ptr<X>, std::shared_ptr<Y>); 

Foo() :

 Foo(std::shared_ptr<X>(new X()), std::shared_ptr<Y>(new Y())); 

: X , Y , std::shared_ptr<X> , std::shared_ptr<Y> . Y , X .

:

 auto p1 = std::shared_ptr<X>(new X()); auto p2 = std::shared_ptr<Y>(new Y()); Foo(p1, p2); 

std::make_shared<Y> ( , ):

 Foo(std::make_shared<X>(), std::make_shared<Y>()); 

. [Meyers2].

:

• .

5.

5.1।

++98 , ( ), , ( , ). virtual , , . ( ), , , . , , . , ++11 override , , , . .

:

• override .
• . , .

5.2।

. , , . . . [Dewhurst].

:

• .

5.3।

, , . , , post_construct pre_destroy. , — . . , : ( ) . (, , .) , ( ), ( ). . [Dewhurst]. , , .

— - .

, C# , , , . C# : , , . , ( , ).

:

• , , .

5.4।

, , delete . , - .

:

• .

6.

— C/C++, . . . « ».

C# unsafe mode, .

6.1.

/++ , : strcpy() , strcat() , sprinf() , etc. ( std::vector<> , etc.) , . (, , , . . Checked Iterators MSDN.) , : , , ; , .

C#, unsafe mode, .

:

• , .
• .
• z-terminated , _s (. ).

6.2. Z-terminated

, . , :

 strncpy(dst,src,n); 

strlen(src)>=n , dst (, ). , , . . — . if(*str) , if(strlen(str)>0) , . [Spolsky].

C# string .

:

• .
• z-terminated , _s (. ).

6.3.

... . printf - , C. , , , , . , .

C# printf , .

:

• . , printf - /.
• .

7.

7.1.

++ , , , . यहाँ एक उदाहरण है:

 const int N = 4, M = 6; int x,                // 1    *px,              // 2    ax[N],            // 3    *apx[N],          // 4    F(char),          // 5    *G(char),          // 6    (*pF)(char),      // 7    (*apF[N])(char),  // 8    (*pax)[N],        // 9    (*apax[M])[N],    // 10    (*H(char))(long);  // 11 

:

1. int ;
2. int ;
3. N int ;
4. N int ;
5. , char int ;
6. , char int ;
7. , char int ;
8. N , char int ;
9. N int ;
10. M N int ;
11. , char , long int .

, . ( .)

* & . ( .)

typedef ( using -). , :

 typedef int(*P)(long); PH(char); 

, .

C# , .

:

• .

7.2.

.

 class X { public:    X(int val = 0); // ... }; 

 X x(5); 

x X , 5.

 X x(); 

x , X , x X , . X , , :

 X x; X x = X(); X x{};    //   C++11 

, , , . [Sutter].

, , C++ ( ). . ( C++ .)

, , , , .

C# , , .

:

• .

8.

8.1. inline ODR

, inline — . , . inline (One Defenition Rule, ODR). . , . , ODR. static : , , . static inline . , , ODR, . , . - , -. .

:

• «» inline . namespace . , .
• — namespace .

8.2.

. . , , , , .

:

• , .
• , : () , -.
• using -: using namespace , using -.
• .

8.3. switch

— break case . ( .) C# .

:

• .

8.4.

++ , — , — . ( class struct ) , . ( , # Java.) — , .

1. , . ( std::string , std::vector , etc.), , .
2. , , .
3. , (slicing), , .

, , , . . , , . , . . — ( =delete ), — explicit .

C# , .

:

• , .
• .

8.5. संसाधन प्रबंधन

++ . , . - ( ), ++11 , , , .

C++ .

C# , . , . (using-) Basic Dispose.

:

• - .

8.6.

«» . , , C++ , STL- - .

. . , . . «», . COM- . (, .) , C++ . — . . . , («» ) , . .

# , . — .

:

• .
• .

8.7.

C++ , : , , . ( !) . , . , . , , . (, .)

C ( ), C++ C ( extern "C" ). C/C++ .

-. #pragma - , , .

, , , .

, , COM. COM-, , ( , ). COM , , .

C# . , — , C#, C# C/C++.

:

• .

8.8.

, . , . C++ . के बदले

 #define XXL 32 

 const int XXL=32; 

. inline .

# ( ).

:

• .

9.

1. . . . , .
2. .
3. . ++ — ++11/14/17.
4. - , - .
5. .

संदर्भ