👨🏼‍🍳 🕰️ ✊🏼 दृश्य स्टूडियो 2019 पूर्वावलोकन 2 में लाइफटाइम प्रोफाइल अपडेट 🌩️ 🌗 🍣

सी ++ कोर गाइडलाइन्स की लाइफटाइम प्रोफाइल, जो सी ++ कोर गाइडलाइन्स का हिस्सा है, का उद्देश्य सी ++ कोड में लाइफलाइन समस्याओं का पता लगाना है, जैसे कि पॉइंटर्स एंड रेफरेंस को लटकाना। यह न्यूनतम एनोटेशन के साथ संकलन समय पर दोषों का पता लगाने के लिए कार्यों के बीच कुछ सरल अनुबंधों के साथ स्रोत में मौजूद प्रकार की जानकारी का उपयोग करता है।

ब्लॉग में मूल

ये मूल अनुबंध हैं जिनका प्रोफ़ाइल कोड का पालन करने की अपेक्षा करता है:

संभावित लटकन सूचक का उपयोग न करें।
किसी अन्य फ़ंक्शन के लिए संभावित लटकाने वाले सूचक को पास न करें।
किसी भी फ़ंक्शन से संभावित झूलने वाले सूचक को वापस न करें।

प्रोफ़ाइल के इतिहास और लक्ष्यों के बारे में अधिक जानकारी के लिए, वर्जन 1.0 के बारे में हर्ब सटर के ब्लॉग पोस्ट को देखें ।

दृश्य स्टूडियो 2019 पूर्वावलोकन 2 में नया क्या है

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

पुनरावृत्तियों के लिए समर्थन, string_ साक्षात्कार, और स्पैन।
कस्टम ओनर और पॉइंटर प्रकारों का बेहतर पता लगाना जो कस्टम प्रकारों को अनुमति देता है जो कंटेनर, ओनिंग-पॉइंटर्स या गैर-ओनिंग पॉइंटर्स की तरह व्यवहार करते हैं।
फ़ंक्शन कॉल पूर्व और बाद की स्थितियों के लिए टाइप-जागरूक डिफ़ॉल्ट नियम झूठी-सकारात्मकता को कम करने और सटीकता में सुधार करने में मदद करते हैं।
कुल प्रकार के लिए बेहतर समर्थन।
सामान्य शुद्धता और प्रदर्शन में सुधार।
कुछ सरल nullptr विश्लेषण।

लाइफटाइम प्रोफ़ाइल परीक्षक नियमों को सक्षम करना

चेकर नियम डिफ़ॉल्ट रूप से सक्षम नहीं हैं। यदि आप नए नियमों को आज़माना चाहते हैं, तो आपको अपने प्रोजेक्ट के लिए चुने गए कोड विश्लेषण नियम को अपडेट करना होगा। आप या तो "C ++ कोर चेक लाइफटाइम नियम" का चयन कर सकते हैं - जो केवल लाइफटाइम प्रोफाइल नियमों को सक्षम करता है - या आप 26489 के माध्यम से 26486 चेतावनी को सक्षम करने के लिए अपने मौजूदा नियम को संशोधित कर सकते हैं।

कोड विश्लेषण गुण पृष्ठ का स्क्रीनशॉट जो C ++ कोर चेक लाइफटाइम नियम नियमों को दर्शाता है।

चेतावनियाँ जब कोड विश्लेषण चलाया जाता है (विश्लेषण> रन कोड विश्लेषण), या यदि आपके पास पृष्ठभूमि कोड विश्लेषण सक्षम है, तो चेतावनी सूची में दिखाई देगी, आजीवन त्रुटियां संपादक के साथ ग्रीन स्क्विगल्स में दिखाई देंगी।

स्रोत कोड में हरे रंग की धार के साथ एक लाइफटाइम प्रोफ़ाइल चेकर चेतावनी दिखाते हुए स्क्रीनशॉट।

उदाहरण

खतरनाक संकेत

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

 void simple_test() { int* px; { int x = 0; px = &x; } *px = 1; // error, dangling pointer to 'x' }

खतरनाक आउटपुट सूचक

झूलने वाले बिंदुओं को वापस करने की भी अनुमति नहीं है। इस स्थिति में, पैरामीटर ppx को आउटपुट पैरामीटर माना जाता है। इस मामले में, यह x को इंगित करने के लिए सेट है जो फ़ंक्शन के अंत में दायरे से बाहर हो जाता है। यह *ppx झूलने छोड़ देता है।

 void out_parameter(int x, int** ppx) // *ppx points to 'x' which is invalid { *ppx = &x; }

झकझोर देने वाला नजारा

अंतिम दो उदाहरण स्पष्ट थे, लेकिन अस्थायी उदाहरण सूक्ष्म कीड़े को पेश कर सकते हैं। क्या आप निम्नलिखित कोड में बग ढूंढ सकते हैं?

 std::string get_string(); void dangling_string_view() { std::string_view sv = get_string(); auto c = sv.at(0); }

इस स्थिति में, स्ट्रिंग व्यू sv को get_string() से get_string() गए अस्थायी स्ट्रिंग इंस्टेंस के साथ बनाया जाता है। अस्थायी स्ट्रिंग को तब नष्ट कर दिया जाता है जो एक अमान्य ऑब्जेक्ट को संदर्भित करते हुए स्ट्रिंग दृश्य छोड़ देता है।

झूलता हुआ भक्षक

कंटेनर में अमान्य पुनरावृत्ति का उपयोग करते समय आजीवन समस्या का सामना करना मुश्किल होता है। नीचे दिए गए मामले में, push_back को कॉल करने से वेक्टर को अपने अंतर्निहित भंडारण को पुनः प्राप्त करना पड़ सकता है जो it पुनरावृत्त को अमान्य करता है।

 void dangling_iterator() { std::vector<int> v = { 1, 2, 3 }; auto it = v.begin(); *it = 0; // ok, iterator is valid v.push_back(4); *it = 0; // error, using an invalid iterator }

इस उदाहरण पर ध्यान देने वाली एक बात यह है कि 'std :: वेक्टर :: push_back' के लिए कोई विशेष हैंडलिंग नहीं है। यह व्यवहार डिफ़ॉल्ट प्रोफ़ाइल नियमों से बाहर है। एक नियम कंटेनरों को एक 'मालिक' के रूप में वर्गीकृत करता है। फिर, जब स्वामी पर एक गैर-कास्ट विधि कहा जाता है, तो इसकी स्वामित्व वाली मेमोरी को अमान्य मान लिया जाता है और मालिक की स्मृति पर इंगित करने वाले पुनरावृत्तियों को भी अमान्य माना जाता है।

संशोधित स्वामी

प्रोफ़ाइल इसके मार्गदर्शन में निर्धारित है। यह अपेक्षा करता है कि फ़ंक्शन मापदंडों को परिभाषित करते समय आपका कोड उस प्रकार के सिस्टम का उपयोग मुहावरेदार तरीके से करता है। इस अगले उदाहरण में, std::unique_ptr , एक 'स्वामी' प्रकार, गैर-कॉन्स्टेंस संदर्भ द्वारा किसी अन्य फ़ंक्शन को दिया जाता है। प्रोफ़ाइल के नियमों के अनुसार, नॉन-कॉस्ट संदर्भ द्वारा पारित किए गए मालिकों को कैली द्वारा संशोधित माना जाता है।

 void use_unique_ptr(std::unique_ptr<int>& upRef); void assumes_modification() { auto unique = std::make_unique<int>(0); // Line A auto ptr = unique.get(); *ptr = 10; // ok, ptr is valid use_unique_ptr(unique); *ptr = 10; // error, dangling pointer to the memory held by 'unique' at Line A }

इस उदाहरण में, हम एक कच्चे सूचक, ptr , unique स्वामित्व वाली स्मृति को प्राप्त करते हैं। तब unique को गैर- use_unique_ptr संदर्भ द्वारा function_unique_ptr फ़ंक्शन के लिए दिया जाता है। क्योंकि यह unique का एक नॉन-कास्ट उपयोग है जहाँ फ़ंक्शन कुछ भी कर सकता है, विश्लेषण मानता है कि unique 'किसी भी तरह से अमान्य है (जैसे कि unique_ptr :: रीसेट) जिससे ptr झूलने लगे।

और उदाहरण

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

ज्ञात मुद्दे

वर्तमान कार्यान्वयन पूरी तरह से विश्लेषण का समर्थन नहीं करता जैसा कि लाइफटाइम प्रोफाइल पेपर में वर्णित है। यहां वे व्यापक श्रेणियां हैं जिन्हें इस रिलीज़ में लागू नहीं किया गया है।

एनोटेशंस - पेपर एनोटेशन (यानी [[gsl::lifetime-const]] समर्थन करता है जो समर्थित नहीं हैं। व्यावहारिक रूप से इसका मतलब है कि यदि डिफ़ॉल्ट विश्लेषण नियम आपके कोड के लिए काम नहीं कर रहे हैं, तो बहुत कुछ नहीं है जो आप झूठी सकारात्मक को दबाने के अलावा कर सकते हैं।
अपवाद - catch ब्लॉक की सामग्री सहित अपवाद हैंडलिंग पथ, वर्तमान में विश्लेषण नहीं किए जाते हैं।
डिफॉल्ट रूल्स फॉर एसटीएल टाइप्स - lifetime-const एनोटेशन के एवज में, पेपर यह सलाह देता है कि दुर्लभ एसटीएल कंटेनर मेंबर फंक्शन के लिए, जहाँ हम डिफॉल्ट्स को ओवरराइड करना चाहते हैं, हम उन्हें ऐसे ट्रीट करते हैं जैसे उन्हें एनोटेट किया गया था। उदाहरण के लिए, std::vector::at का एक अधिभार std::vector::at const नहीं है क्योंकि यह एक नॉन-कॉस्ट संदर्भ को लौटा सकता है - हालांकि हम जानते हैं कि इसे कॉलिंग lifetime-const क्योंकि यह वेक्टर की मेमोरी को अमान्य नहीं करता है। हमने सभी एसटीएल कंटेनर प्रकारों के इस निहित एनोटेशन को करने के लिए काम पूरा नहीं किया है।
लैम्ब्डा कैप्चर - यदि स्टैम्बल वैरिएबल को लैम्ब्डा में रेफरेंस द्वारा कैप्चर किया जाता है, तो हम वर्तमान में यह पता नहीं लगाते हैं कि लैम्ब्डा कैप्चर किए गए वेरिएबल का स्कोप छोड़ता है या नहीं।
```
 auto lambda_test() { int x; auto captures_x = [&x] { return x; }; return captures_x; // returns a dangling reference to 'x' } 
```

लपेट लो

दृश्य स्टूडियो 2019 पूर्वावलोकन 2 में लाइफटाइम प्रोफ़ाइल परीक्षक की कोशिश करें। हमें उम्मीद है कि यह आपकी परियोजनाओं में जीवन भर की समस्याओं को पहचानने में मदद करेगा। यदि आप गलत सकारात्मक या गलत नकारात्मक पाते हैं, तो कृपया उन्हें रिपोर्ट करें ताकि हम उन परिदृश्यों को प्राथमिकता दे सकें जो आपके लिए महत्वपूर्ण हैं। यदि आपके पास इस चेक के साथ सुझाव या समस्याएं हैं - या किसी भी दृश्य स्टूडियो सुविधा - या तो समस्या की रिपोर्ट करें या डेवलपर समुदाय पर पोस्ट करें और हमें बताएं। हम ट्विटर पर @VisualC पर भी हैं।

दृश्य स्टूडियो 2019 पूर्वावलोकन 2 में लाइफटाइम प्रोफाइल अपडेट