विजुअल C ++ 2012 पुस्तकालयों में त्रुटियां मिलीं

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

परिचय

Visual Studio विकास परिवेश स्थिर कोड विश्लेषण की अनुमति देता है। यह विश्लेषण बेहद उपयोगी और उपयोग में आसान है। हालांकि, यह समझा जाना चाहिए कि विज़ुअल स्टूडियो बड़ी संख्या में कार्य करता है। इसका मतलब यह है कि एक एकल फ़ंक्शन हमेशा विशेष टूल को खो देता है। विज़ुअल असिस्ट की तुलना में रीफैक्टरिंग और कलरिंग फ़ंक्शंस खो देते हैं। एकीकृत छवि संपादन की सुविधा Adobe Photoshop या CorelDRAW की तुलना में स्वाभाविक रूप से खराब है। स्थैतिक कोड विश्लेषण के कार्य के साथ स्थिति समान है।

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

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

खुद के लिए अप्रत्याशित रूप से, हैडर में। * फाइलें हमने कई त्रुटियों को देखा। हमने विज़ुअल स्टूडियो 2012 में शामिल फ़ाइलों के बारे में अधिक विस्तार से जांच करने का निर्णय लिया। अर्थात्, ऐसे फ़ोल्डर:

• प्रोग्राम फ़ाइलें (x86) \ Microsoft दृश्य स्टूडियो 11.0 \ VC \ शामिल हैं
• प्रोग्राम फ़ाइलें (x86) \ Microsoft दृश्य स्टूडियो 11.0 \ VC \ crt
• प्रोग्राम फ़ाइलें (x86) \ Microsoft दृश्य स्टूडियो 11.0 \ VC \ atlmfc

एक पूर्ण चेक काम नहीं करता था, क्योंकि हमारे पास पुस्तकालयों के निर्माण के लिए प्रोजेक्ट या मेक-फाइल्स नहीं हैं। इसलिए, लाइब्रेरी कोड के केवल एक मामूली हिस्से की जांच करना संभव था। सत्यापन की अपूर्णता के बावजूद, परिणाम बहुत दिलचस्प हैं।

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

कुछ संदिग्ध स्पॉट मिले

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

अजीब सा चक्र

यह संदिग्ध कोड पहले पाया गया था। उन्होंने अध्ययन की निरंतरता के लिए प्रोत्साहन के रूप में कार्य किया।

template <class T> class ATL_NO_VTABLE CUtlProps : public CUtlPropsBase { .... HRESULT GetIndexOfPropertyInSet(....) { .... for(ULONG ul=0; ul<m_pUPropSet[*piCurSet].cUPropInfo; ul++) { if( dwPropertyId == pUPropInfo[ul].dwPropId ) *piCurPropId = ul; return S_OK; } return S_FALSE; } .... }; 

V612 लूप के भीतर बिना शर्त 'वापसी'। atldb.h 4829

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

 for(ULONG ul=0; ul<m_pUPropSet[*piCurSet].cUPropInfo; ul++) { if( dwPropertyId == pUPropInfo[ul].dwPropId ) { *piCurPropId = ul; return S_OK; } } 

संदेहास्पद प्रक्षेपण

मैं कड़ी मेहनत से पढ़ी गई मिसाल के लिए माफी माँगता हूँ। टर्नरी ऑपरेटर की स्थिति पर ध्यान दें।

 // TEMPLATE FUNCTION proj _TMPLT(_Ty) inline _CMPLX(_Ty) proj(const _CMPLX(_Ty)& _Left) { // return complex projection return (_CMPLX(_Ty)( _CTR(_Ty)::_Isinf(real(_Left)) || _CTR(_Ty)::_Isinf(real(_Left)) ? _CTR(_Ty)::_Infv(real(_Left)) : real(_Left), imag(_Left) < 0 ? -(_Ty)0 : (_Ty)0)); } 

V501 समान उप-अभिव्यक्तियाँ हैं '_Ctraits <_Ty> :: _ Isinf (वास्तविक (_Left))' बाईं ओर और 'दाईं ओर' || ऑपरेटर। xcomplex 780

हालत में, "_CTR (_Ty) :: _ Isinf (वास्तविक (_Lft))" की अभिव्यक्ति दो बार दोहराई जाती है। यह कहना मुश्किल है कि क्या यहां कोई त्रुटि है और कोड को कैसे ठीक किया जाए। हालांकि, यह सुविधा स्पष्ट रूप से ध्यान देने योग्य है।

अनावश्यक जांच

 template<typename BaseType, bool t_bMFCDLL = false> class CSimpleStringT { .... void Append(_In_reads_(nLength) PCXSTR pszSrc, _In_ int nLength) { .... UINT nOldLength = GetLength(); if (nOldLength < 0) { // protects from underflow nOldLength = 0; } .... }; 

V547 अभिव्यक्ति 'nOldLength <0' हमेशा झूठी होती है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। Atlsimpstr.h 420

यहां कोई गलती नहीं है। कोड को देखते हुए, लाइन की लंबाई नकारात्मक नहीं हो सकती। CSimpleStringT वर्ग की इसी जाँच होती है। तथ्य यह है कि चर nOldLength एक अहस्ताक्षरित प्रकार का है, कुछ भी खराब नहीं करता है। वैसे भी, लंबाई हमेशा सकारात्मक होती है। यह सिर्फ बेमानी कोड है।

गलत लाइन का गठन

 template <class T> class CHtmlEditCtrlBase { .... HRESULT SetDefaultComposeSettings( LPCSTR szFontName=NULL, .....) const { CString strBuffer; .... strBuffer.Format(_T("%d,%d,%d,%d,%s,%s,%s"), bBold ? 1 : 0, bItalic ? 1 : 0, bUnderline ? 1 : 0, nFontSize, szFontColor, szBgColor, szFontName); .... } }; 

V576 गलत प्रारूप। 'प्रारूप' फ़ंक्शन के आठवें वास्तविक तर्क की जाँच करने पर विचार करें। Wchar_t प्रकार के प्रतीकों के स्ट्रिंग के लिए सूचक अपेक्षित है। afxhtml.h 826

यह कोड UNICODE कार्यक्रमों में एक गलत संदेश देता है। 'फॉर्मेट ()' फंक्शन में एलपीसीटीएसआर टाइप के आठवें तर्क की अपेक्षा की जाती है। लेकिन चर 'szFontName' हमेशा LPCSTR प्रकार का होता है।

नकारात्मक बंदरगाह

 typedef WORD ATL_URL_PORT; class CUrl { ATL_URL_PORT m_nPortNumber; .... inline BOOL Parse(_In_z_ LPCTSTR lpszUrl) { .... //get the port number m_nPortNumber = (ATL_URL_PORT) _ttoi(tmpBuf); if (m_nPortNumber < 0) goto error; .... }; 

V547 अभिव्यक्ति 'm_nPortNumber <0' हमेशा झूठी होती है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। Atlutil.h 2775

यह जांचना कि पोर्ट नंबर शून्य से कम है, काम नहीं करेगा। चर 'm_nPortNumber' में अहस्ताक्षरित प्रकार 'शब्द' है। 'WORD' प्रकार 'अहस्ताक्षरित छोटा' है।

अपरिभाषित व्यवहार

निम्न मैक्रो Visual C ++ हैडर फ़ाइलों में है।

 #define DXVABitMask(__n) (~((~0) << __n)) 

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

64-बिट मोड में गलत संचालन

64-बिट C / C ++ एप्लिकेशन को विकसित करने के बारे में हमारे पाठों में इस 64-बिट त्रुटि पैटर्न पर विस्तार से चर्चा की गई है। यह समझने के लिए कि गलती क्या है, हम सुझाव देते हैं कि आप खुद को पाठ संख्या 12 से परिचित कराएं ।

 class CWnd : public CCmdTarget { .... virtual void WinHelp(DWORD_PTR dwData, UINT nCmd = HELP_CONTEXT); .... }; class CFrameWnd : public CWnd { .... }; class CFrameWndEx : public CFrameWnd { .... virtual void WinHelp(DWORD dwData, UINT nCmd = HELP_CONTEXT); .... }; 

V301 अनपेक्षित फ़ंक्शन ओवरलोडिंग व्यवहार। व्युत्पन्न वर्ग 'CFrameWndEx' और बेस क्लास 'CFrameWnd' में फ़ंक्शन 'WinHelpW' का पहला तर्क देखें। afxframewndex.h 154

'WinHelp' फ़ंक्शन को गलत तरीके से 'CFrameWndEx' वर्ग में घोषित किया गया है। पहले तर्क का प्रकार 'DWORD_PTR' होना चाहिए। कुछ अन्य वर्गों में एक समान त्रुटि देखी जा सकती है:

• V301 अनपेक्षित फ़ंक्शन ओवरलोडिंग व्यवहार। व्युत्पन्न वर्ग 'CMDIFrameWndEx' और बेस क्लास 'CFrameWnd' में फ़ंक्शन 'WinHelpW' का पहला तर्क देखें। afxmdiframewndex.h 237
• V301 अनपेक्षित फ़ंक्शन ओवरलोडिंग व्यवहार। व्युत्पन्न वर्ग 'CMDIFrameWndEx' और बेस क्लास 'CMDIFrameWnd' में फ़ंक्शन 'WinHelpW' का पहला तर्क देखें। afxmdiframewndex.h 237
• V301 अनपेक्षित फ़ंक्शन ओवरलोडिंग व्यवहार। व्युत्पन्न वर्ग 'COLEIPFrameWndEx' और बेस क्लास 'CFrameWnd' में फ़ंक्शन 'WinHelpW' का पहला तर्क देखें। afxoleipframewndex.h 130
• V301 अनपेक्षित फ़ंक्शन ओवरलोडिंग व्यवहार। व्युत्पन्न वर्ग 'COLEIPFrameWndEx' और बेस क्लास 'COLEIPFrameWnd' में फ़ंक्शन 'WinHelpW' का पहला तर्क देखें। afxoleipframewndex.h 130
• V301 अनपेक्षित फ़ंक्शन ओवरलोडिंग व्यवहार। व्युत्पन्न वर्ग 'कॉलेडोकिपफ्रेमवेन्डएक्स' और बेस क्लास 'सीफ्रेमवेन्ड' में 'विन्हेल्प डब्ल्यूडब्ल्यू' फ़ंक्शन का पहला तर्क देखें। afxoledocipframewndex.h 129
• V301 अनपेक्षित फ़ंक्शन ओवरलोडिंग व्यवहार। फंक्स्ड क्लास 'COLEDocIPFrameWndEx' और बेस क्लास 'COLEIPFrameWnd' में फ़ंक्शन 'WinHelpW' का पहला तर्क देखें। afxoledocipframewndex.h 129
• V301 अनपेक्षित फ़ंक्शन ओवरलोडिंग व्यवहार। फंक्स्ड क्लास 'COLEDocIPFrameWndEx' और बेस क्लास 'COLEDocIPFrameWnd' में फंक्शन 'WinHelpW' का पहला तर्क देखें। afxoledocipframewndex.h 129

शुरुआत में सूचक का उपयोग किया जाता है और फिर NULL की तुलना में

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

 BOOL CDockablePane::PreTranslateMessage(MSG* pMsg) { .... CBaseTabbedPane* pParentBar = GetParentTabbedPane(); CPaneFrameWnd* pParentMiniFrame = pParentBar->GetParentMiniFrame(); if (pParentBar != NULL && (pParentBar->IsTracked() || pParentMiniFrame != NULL && pParentMiniFrame->IsCaptured() ) ) .... } 

V595 'pParentBar' पॉइंटर को nullptr के खिलाफ सत्यापित होने से पहले उपयोग किया गया था। चेक लाइन: 2840, 2841। afxdockablepane.cpp 2840

देखें, शुरुआत में, GetParentMiniFrame () फ़ंक्शन को कॉल करने के लिए 'pParentBar' पॉइंटर का उपयोग किया जाता है। Zetas को अचानक संदेह होता है कि यह पॉइंटर NULL हो सकता है और इसी जांच की जाती है।

 AFX_CS_STATUS CDockingManager::DeterminePaneAndStatus(....) { .... CDockablePane* pDockingBar = DYNAMIC_DOWNCAST(CDockablePane, *ppTargetBar); if (!pDockingBar->IsFloating() && (pDockingBar->GetCurrentAlignment() & dwEnabledAlignment) == 0) { return CS_NOTHING; } if (pDockingBar != NULL) { return pDockingBar->GetDockingStatus( pt, nSensitivity); } .... } 

V595 nullptr के खिलाफ सत्यापित होने से पहले 'pDockingBar' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 582, 587. afxdockingmanager.cpp 582

शुरुआत में, सूचक 'pDockingBar' सक्रिय रूप से उपयोग किया जाता है, और फिर इसे अचानक NULL की तुलना में किया जाता है।

और एक अंतिम उदाहरण:

 void CFrameImpl::AddDefaultButtonsToCustomizePane(....) { .... for (POSITION posCurr = lstOrigButtons.GetHeadPosition(); posCurr != NULL; i++) { CMFCToolBarButton* pButtonCurr = (CMFCToolBarButton*)lstOrigButtons.GetNext(posCurr); UINT uiID = pButtonCurr->m_nID; if ((pButtonCurr == NULL) || (pButtonCurr->m_nStyle & TBBS_SEPARATOR) || (....) { continue; } .... } 

V595 nullptr के खिलाफ सत्यापित होने से पहले 'pButtonCurr' पॉइंटर का उपयोग किया गया था। जाँच लाइनें: 1412, 1414। afxframeimpl.cpp 1412

वर्ग 'm_nID' के सदस्य से बेझिझक संपर्क करें। और फिर इसे इस स्थिति से देखा जा सकता है कि सूचक 'pButtonCurr' 0 हो सकता है।

नष्ट वस्तु का उपयोग करना

 CString m_strBrowseFolderTitle; void CMFCEditBrowseCtrl::OnBrowse() { .... LPCTSTR lpszTitle = m_strBrowseFolderTitle != _T("") ? m_strBrowseFolderTitle : (LPCTSTR)NULL; .... } 

V623 ':?' 'संचालक का निरीक्षण करने पर विचार करें। एक अस्थायी ऑब्जेक्ट बनाया जा रहा है और बाद में नष्ट हो गया है। afxeditbrowsectrl.cpp 308

टर्नरी ऑपरेटर विभिन्न प्रकारों के मूल्यों को वापस नहीं कर सकता। इसलिए, CString प्रकार की एक वस्तु को "(LPCTSTR) NULL" से स्पष्ट रूप से बनाया जाएगा। फिर इसके बफ़र के लिए एक सूचक को इस खाली स्ट्रिंग से लिया जाएगा। मुसीबत यह है कि CString जैसी अस्थायी वस्तु नष्ट हो जाएगी। परिणामस्वरूप, 'lpszTitle' पॉइंटर का मान अमान्य हो जाता है और आप इसके साथ काम नहीं कर सकते। यहां आप इस त्रुटि पैटर्न का अधिक विस्तृत विवरण पढ़ सकते हैं।

समय के साथ गलत काम

 UINT CMFCPopupMenuBar::m_uiPopupTimerDelay = (UINT) -1; .... void CMFCPopupMenuBar::OnChangeHot(int iHot) { .... SetTimer(AFX_TIMER_ID_MENUBAR_REMOVE, max(0, m_uiPopupTimerDelay - 1), NULL); .... } 

V547 अभिव्यक्ति '(0)> (m_uiPopupTimerDelay - 1)' हमेशा गलत है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। Afxpopupmenubar.cpp 968

'-1' मान का उपयोग एक विशेष ध्वज के रूप में किया जाता है। 'अधिकतम' मैक्रो का उपयोग करते हुए, प्रोग्रामर m_uiPopupTimerDelay वैरिएबल में नकारात्मक मानों से बचाव करना चाहते थे। यह काम नहीं करेगा, क्योंकि चर का एक अहस्ताक्षरित प्रकार है। यह हमेशा शून्य से अधिक या बराबर होता है। सही कोड कुछ इस तरह दिखना चाहिए:

 SetTimer(AFX_TIMER_ID_MENUBAR_REMOVE, m_uiPopupTimerDelay == (UINT)-1 ? 0 : m_uiPopupTimerDelay - 1, NULL); 

एक समान त्रुटि यहाँ है:

• V547 अभिव्यक्ति '(0)> (m_uiPopupTimerDelay - 1)' हमेशा गलत है। अहस्ताक्षरित प्रकार का मान कभी नहीं होता है <0। Afxribbonpanelmenu.cpp 880

अर्थहीन रेखा

 BOOL CMFCTasksPaneTask::SetACCData(CWnd* pParent, CAccessibilityData& data) { .... data.m_nAccHit = 1; data.m_strAccDefAction = _T("Press"); data.m_rectAccLocation = m_rect; pParent->ClientToScreen(&data.m_rectAccLocation); data.m_ptAccHit; return TRUE; } 

V607 मालिकाना अभिव्यक्ति 'data.m_ptAccHit'। afxtaskspane.cpp 96

"Data.m_ptAccHit?" क्या है? शायद यहाँ वे इस चर के लिए कुछ मूल्य निर्दिष्ट करना भूल गए?

शायद आपको एक और 0 की आवश्यकता है?

 BOOL CMFCTasksPane::GetMRUFileName(....) { .... const int MAX_NAME_LEN = 512; TCHAR lpcszBuffer [MAX_NAME_LEN + 1]; memset(lpcszBuffer, 0, MAX_NAME_LEN * sizeof(TCHAR)); if (GetFileTitle((*pRecentFileList)[nIndex], lpcszBuffer, MAX_NAME_LEN) == 0) { strName = lpcszBuffer; return TRUE; } .... } 

V512 'मेमसेट' फ़ंक्शन की एक कॉल बफर 'lpcszBuffer' को कम करेगी। afxtaskspane.cpp 2626

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

 memset(lpcszBuffer, 0, (MAX_NAME_LEN + 1) * sizeof(TCHAR)); 

अजीब 'अगर'

 void CMFCVisualManagerOfficeXP::OnDrawBarGripper(....) { .... if (bHorz) { rectFill.DeflateRect(4, 0); } else { rectFill.DeflateRect(4, 0); } .... } 

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। afxvisualmanagerofficexp.cpp 264

खतरनाक वर्ग single_link_registry

यदि आप वर्ग 'single_link_registry' का उपयोग करते हैं तो आपका आवेदन अप्रत्याशित रूप से समाप्त हो सकता है, भले ही आप सभी अपवादों को सही ढंग से संभाल लें। आइए कक्षा 'विधवा एकल' के विनाश को देखें:

 virtual ~single_link_registry() { // It is an error to delete link registry with links // still present if (count() != 0) { throw invalid_operation( "Deleting link registry before removing all the links"); } } 

V509 विध्वंसक के अंदर 'थ्रो' ऑपरेटर को try..catch ब्लॉक के भीतर रखा जाना चाहिए। विध्वंसक के अंदर अपवाद उठाना अवैध है। Agent.h 759

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

समान ख़राब विध्वंसक:

• V509 विध्वंसक के अंदर 'थ्रो' ऑपरेटर को try..catch ब्लॉक के भीतर रखा जाना चाहिए। विध्वंसक के अंदर अपवाद उठाना अवैध है। concrt.h 4747
• V509 विध्वंसक के अंदर 'थ्रो' ऑपरेटर को try..catch ब्लॉक के भीतर रखा जाना चाहिए। विध्वंसक के अंदर अपवाद उठाना अवैध है। एजेंटों.एच 934
• V509 विध्वंसक के अंदर 'थ्रो' ऑपरेटर को try..catch ब्लॉक के भीतर रखा जाना चाहिए। विध्वंसक के अंदर अपवाद उठाना अवैध है। taskcollection.cpp 880

एक और अजीब लूप

 void CPreviewView::OnPreviewClose() { .... while (m_pToolBar && m_pToolBar->m_pInPlaceOwner) { COleIPFrameWnd *pInPlaceFrame = DYNAMIC_DOWNCAST(COleIPFrameWnd, pParent); if (!pInPlaceFrame) break; CDocument *pViewDoc = GetDocument(); if (!pViewDoc) break; // in place items must have a server document. COleServerDoc *pDoc = DYNAMIC_DOWNCAST(COleServerDoc, pViewDoc); if (!pDoc) break; // destroy our toolbar m_pToolBar->DestroyWindow(); m_pToolBar = NULL; pInPlaceFrame->SetPreviewMode(FALSE); // restore toolbars pDoc->OnDocWindowActivate(TRUE); break; } .... } 

V612 लूप के भीतर बिना शर्त 'ब्रेक'। viewprev.cpp 476

लूप में कोई 'जारी' बयान नहीं हैं। लूप के अंत में 'ब्रेक' है। यह बहुत अजीब है। एक चक्र हमेशा केवल एक बार चलता है। यहां या तो कोई त्रुटि है या 'जबकि' को 'यदि' के साथ बदलना बेहतर है।

अजीब बात है

कोड पर अन्य छोटी टिप्पणियाँ हैं जो सूची के लिए दिलचस्प नहीं हैं। हम केवल एक उदाहरण देते हैं, ताकि यह स्पष्ट हो जाए कि दांव पर क्या है।

Afxdrawmanager.cpp फ़ाइल में, किसी कारण से, पाई नंबर के लिए एक स्थिरांक सेट किया जाता है:

 const double AFX_PI = 3.1415926; 

V624 निरंतर 3.1415926 का उपयोग किया जा रहा है। परिणामी मूल्य गलत हो सकता है। <Math.h> से M_PI निरंतर का उपयोग करने पर विचार करें। afxdrawmanager.cpp 22

यह निश्चित रूप से कोई गलती नहीं है और निरंतरता की सटीकता पर्याप्त है। लेकिन यह स्पष्ट नहीं है कि M_PI स्थिरांक का उपयोग क्यों न किया जाए, जो अधिक सटीक रूप से सेट किया गया है:

 #define M_PI 3.14159265358979323846 

विजुअल C ++ डेवलपर्स को कॉल करना

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

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

निष्कर्ष

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

हमें दृश्य C ++ पुस्तकालयों में त्रुटियां मिलीं, हालांकि वहां स्थैतिक विश्लेषण है। हमें क्लैग कंपाइलर में कीड़े मिले, हालांकि इसमें स्थैतिक विश्लेषण है। हमें प्राप्त करें और हम नियमित रूप से आपकी परियोजना में त्रुटियां पाएंगे। हमारे पास विजुअल स्टूडियो 2005, 2008, 2010, 2012 में एक महान प्रशिक्षु है और पृष्ठभूमि में त्रुटियों को देखने में सक्षम है।