यूनिकॉर्न को माइक्रोवेव में दिलचस्पी हो गई

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

μManager

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

प्रोजेक्ट साइट: माइक्रो-मैनेजर ।

विश्लेषण, हमेशा की तरह, पीवीएस-स्टूडियो विश्लेषक का उपयोग करके प्रदर्शन किया गया था। वैसे, यदि आप चूक गए हैं, तो यहां यह तुलना है कि हमारे संभावित उपयोगकर्ता इंतजार कर रहे हैं: " कोड एनालिसर्स की तुलना: CppCat, Cppcheck, PVS-Studio, Visual Studio "।

यह गेय विषयांतर का अंत है। चलो दिलचस्प कोड स्निपेट्स देखना शुरू करते हैं।

लंबी! = int

ΜManager परियोजना क्रॉस-प्लेटफ़ॉर्म होने का दावा करती है। इसलिए, 'लंबे' के प्रकार से सावधान रहना चाहिए। 32-बिट सिस्टम पर, 'लंबे' प्रकार का आकार 'इंट' प्रकार के आकार के समान होता है। लेकिन 64-बिट सिस्टम में यह अलग हो सकता है। Win64 में, 'लंबे' प्रकार 32-बिट बना रहा। लिनक्स की 64-बिट दुनिया में, एक और डेटा मॉडल अपनाया जाता है, जिसमें 'लंबी' 64-बिट है। इस प्रकार का उपयोग करके सतर्कता बरती जानी चाहिए।

ΜManager परियोजना में निम्नलिखित विफल कोड हैं:

typedef struct _DCMOTSTATUS { unsigned short wChannel; // Channel ident. unsigned int lPosition; // Position in encoder counts. unsigned short wVelocity; // Velocity in encoder counts/sec. unsigned short wReserved; // Controller specific use unsigned int dwStatusBits; // Status bits (see #defines below). } DCMOTSTATUS; int MotorStage::ParseStatus(...., DCMOTSTATUS& stat) { .... memcpy(&stat.lPosition, buf + bufPtr, sizeof(long)); //<<<(1) bufPtr += sizeof(long); memcpy(&stat.wVelocity, buf + bufPtr, sizeof(unsigned short)); bufPtr += sizeof(unsigned short); memcpy(&stat.wReserved, buf + bufPtr, sizeof(unsigned short)); bufPtr += sizeof(unsigned short); memcpy(&stat.dwStatusBits, buf + bufPtr, sizeof(unsigned long)); //<<<(2) return DEVICE_OK; } 

लाइन (1) और (2) में, डेटा को 'int' के वैरिएबल पर कॉपी किया जाता है। प्रकार 'लंबे' के आकार के बराबर बाइट्स की संख्या की नकल की जाती है। याद रखें कि 64-बिट प्रोग्राम में, 'लॉन्ग' 8 बाइट्स पर कब्जा कर सकता है। और टाइप 'int' केवल 4 बाइट्स लेता है।

मामले में (1) चिंता की कोई बात नहीं है। संरचना के निम्नलिखित सदस्यों के मूल्य को बदलें। फिर इन सदस्यों को फिर से भरा जाएगा। पहले से ही सही है।

लेकिन मामला (2) महत्वपूर्ण है। अंतिम सदस्य का मूल्य बदल जाता है। संरचना के बाहर एक रिकॉर्ड होगा। यह क्या भाग्य और चंद्रमा के चरण पर निर्भर करेगा।

पीवीएस-स्टूडियो नैदानिक ​​संदेशों के लिए त्रुटियों का पता लगाया जाता है:

• V512 'memcpy' फ़ंक्शन के कॉल से बफ़र का ओवरफ़्लो हो जाएगा 'और stat.lPosition'। MotorStage.cpp 247
• V512 'memcpy' फ़ंक्शन के कॉल से बफ़र का ओवरफ़्लो हो जाएगा & stat.dwStatusBits '। MotorStage.cpp 256

कचरा कम्पेक्टर बंद करो!

 const unsigned char stopSgn[2] = {0x04, 0x66}; int MotorStage::Stop() { .... if (memcmp(stopSgn, answer, sizeof(stopSgn) != 0)) return ERR_UNRECOGNIZED_ANSWER; .... } 

त्रुटि यह है कि मेमकैंप () फ़ंक्शन केवल एक बाइट की तुलना करता है। क्यों? आपत्तिजनक गलती। समापन ब्रैकेट वहां नहीं लगाया गया है। तुलना करने के लिए बाइट्स की संख्या के रूप में गणना की जाती है: sizeof (stopSgn)! = 0. यह अभिव्यक्ति मूल्य 'सच' के बराबर है, जो एक में बदल जाता है।

हालत इस तरह होनी चाहिए:

 if (memcmp(stopSgn, answer, sizeof(stopSgn)) != 0) 

डायग्नोस्टिक्स द्वारा त्रुटि का पता लगाया गया था: V526 'मेमकैंप' फ़ंक्शन 0 रिटर्न करता है यदि संबंधित बफ़र्स समान हैं। गलतियों के लिए स्थिति की जांच करने पर विचार करें। MotorStage.cpp 385

पहचान की तुलना

 const char* g_Out = "Out"; int FieldDiaphragm::OnCondensor(....) { .... std::string value; .... if (value == g_Out) return g_hub.SetCondensorPosition(*this, *GetCoreCallback(), 0); else if (value == g_Out) return g_hub.SetCondensorPosition(*this, *GetCoreCallback(), 1); .... } 

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

त्रुटि निदान: V517 'if (A) {...} का उपयोग अगर (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। चेक लाइनें: 1455, 1457. LeicaDMR.cpp 1455

एक समान त्रुटि के साथ कोड का एक और टुकड़ा है। जाहिर है, कुछ पहिया की स्थिति निर्धारित करने में समस्याएं होंगी:

 class Wheel : public CStateDeviceBase<Wheel> { .... unsigned wheelNumber_; .... }; int Wheel::SetWheelPosition(int position) { unsigned char cmd[4]; cmd[0] = moduleId_; cmd[2] = 0; cmd[3] = 58; if (wheelNumber_ == 1) { switch (position) { case 0: cmd[1] = 49; break; case 1: cmd[1] = 50; break; case 2: cmd[1] = 51; break; case 3: cmd[1] = 52; break; case 4: cmd[1] = 53; break; case 5: cmd[1] = 54; break; } } else if (wheelNumber_ == 1) { switch (position) { case 0: cmd[1] = 33; break; case 1: cmd[1] = 64; break; case 2: cmd[1] = 35; break; case 3: cmd[1] = 36; break; case 4: cmd[1] = 37; break; case 5: cmd[1] = 94; break; } .... } 

PVS- स्टूडियो डायग्नोस्टिक संदेश: V517 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। चेक लाइनें: 645, 654. लुडल.कैप 645

लगता है हम कुछ भूल गए हैं।

मैं इस कोड को देखने का सुझाव देता हूं। ध्यान दें कि इसमें क्या कमी है?

 class MP285 { .... static int GetMotionMode() { return m_nMotionMode; } .... }; int ZStage::_SetPositionSteps(....) { .... if (MP285::GetMotionMode == 0) { long lOldZPosSteps = (long)MP285::Instance()->GetPositionZ(); dSec = (double)labs(lZPosSteps-lOldZPosSteps) / dVelocity; } else { dSec = (double)labs(lZPosSteps) / dVelocity; } .... } 

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

निदानकर्ता द्वारा त्रुटि का पता लगाया गया था: V516 एक विषम अभिव्यक्ति का निरीक्षण करने पर विचार करें। नॉन-नल फ़ंक्शन पॉइंटर की तुलना नल से की जाती है: 'MP285 :: GetMotionMode == 0'। MP285ZStage.cpp 558

अकेला भटकने वाला

 int HalogenLamp::SetIntensity(long intensity) { .... command_stream.str().c_str(); .... } 

यह क्या है रिफैक्टरिंग का साइड इफेक्ट? अधूरा कोड? हानिरहित अतिरिक्त रेखा या गलती?

ऐसी दो जगहें हैं जहाँ आप ऐसे अकेले भटक सकते हैं:

• V530 'c_str' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। ZeissCAN.cpp 1553
• V530 'c_str' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। ZeissCAN.cpp 2800

ब्राह्मणों ने

 int LeicaScopeInterface::GetDICTurretInfo(....) { .... std::string tmp; .... if (tmp == "DIC-TURRET") scopeModel_->dicTurret_.SetMotorized(true); else scopeModel_->dicTurret_.SetMotorized(true); .... } 

यह सॉफ्टवेयर ब्राह्मण जैसा दिखता है। भले ही शर्त पूरी हो या न हो, एक ही कोड निष्पादित होता है।

चेतावनी: V523 'तब' कथन 'और' कथन के बराबर है। LeicaDMIScopeInterface.cpp 1296

इसी तरह की एक और गलती। यहां उसी लाइनों की तुलना की जाती है। इस कोड में संभवतः एक टाइपो शामिल है:

 int XLedDev::Initialize() { .... if (strcmp( XLed::Instance()->GetXLedStr(XLed::XL_WLedDevName + m_nLedDevNumber).c_str(), XLed::Instance()->GetXLedStr(XLed::XL_WLedDevName + m_nLedDevNumber).c_str() ) != 0) .... } 

चेतावनी: V549 'strcmp' फ़ंक्शन का पहला तर्क दूसरे तर्क के बराबर है। XLedDev.cpp 119

कुछ फिट नहीं है

'असत्य' और 'सत्य' मानों को 'int' टाइप किया जा सकता है:

• झूठ 0 हो जाता है;
• सच 1 हो जाता है।

उदाहरण के लिए, यहां एक कोड है जो सफलतापूर्वक संकलित करता है:

 int F() { return false; } 

एफ (एफ) रिटर्न 0।

कभी-कभी लोग गलती करते हैं और त्रुटि स्थिति के बजाय जो 'int' प्रकार की होती है, वे 'गलत' या 'true' वापस करते हैं। यह भूलने की बीमारी के कारण है। यदि त्रुटि स्थिति 0 के मान से एन्कोडेड है तो ठीक है।

यदि त्रुटि स्थिति शून्य से भिन्न मानों से एन्कोडेड है, तो समस्या उत्पन्न होती है। यह वास्तव में μManager परियोजना में होता है।

निम्नलिखित पूर्वनिर्धारित मूल्य उपलब्ध हैं:

 #define DEVICE_OK 0 #define DEVICE_ERR 1 // generic, undefined error #define DEVICE_INVALID_PROPERTY 2 #define DEVICE_INVALID_PROPERTY_VALUE 3 #define DEVICE_INVALID_PROPERTY_TYPE 5 .... 

ध्यान दें कि 0 का अर्थ है कि सब कुछ ठीक है। अन्य मान किसी प्रकार की त्रुटि की उपस्थिति का संकेत देते हैं।

मुझे ऐसा लगता है कि μManager परियोजना कोड में 'सत्य', 'असत्य' की स्थितियों और मूल्यों के साथ एक गड़बड़ है।

CreateProperty () फ़ंक्शन पर विचार करें:

 int MM::PropertyCollection::CreateProperty(....) { if (Find(pszName)) return DEVICE_DUPLICATE_PROPERTY; .... if (!pProp->Set(pszValue)) return false; .... return DEVICE_OK; } 

ध्यान दें कि यदि कॉल pProp-> सेट (pszValue) विफल रहा है, तो फ़ंक्शन 'गलत' लौटाता है। यह पता चला है कि फ़ंक्शन DEVICE_OK की स्थिति देता है। यह बहुत अजीब है।

कोड का एक और संदिग्ध टुकड़ा:

 int MM::PropertyCollection::RegisterAction( const char* pszName, MM::ActionFunctor* fpAct) { MM::Property* pProp = Find(pszName); if (!pProp) return DEVICE_INVALID_PROPERTY; pProp->RegisterAction(fpAct); return true; } 

अंत में, हम देखते हैं "वापसी सच है;"। इसका मतलब है कि फ़ंक्शन DEVICE_ERR 1 (सामान्य, अपरिभाषित त्रुटि) की स्थिति लौटाएगा। उसी समय, यह मुझे लगता है कि सब कुछ वास्तव में अच्छा है।

शायद इसे पढ़कर अजीब लगेगा कि मैं इन जगहों को संदिग्ध क्यों कहता हूं, और यह नहीं कहता कि ये गलतियाँ हैं। तथ्य यह है कि विशेष मामलों को उजागर करने के लिए विशेष रूप से स्थानों में 'गलत' का उपयोग किया जाता है। एक उदाहरण:

 int XYStage::Home() { .... if (ret != DEVICE_OK) { ostringstream os; os << "ReadFromComPort failed in " "XYStage::Busy, error code:" << ret; this->LogMessage(os.str().c_str(), false); return false; // Error, let's pretend all is fine } .... } 

टिप्पणी पर ध्यान दें। एक त्रुटि हुई है। लेकिन हम दिखावा करेंगे कि सब कुछ ठीक है, शून्य लौट रहा है। शायद इस कोड की ख़ासियत पर ज़ोर देने के लिए DEVICE_OK के बजाय 'गलत' लिखा गया है।

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



किसी भी मामले में, इस तरह के कोड से बहुत खराब गंध आती है।

यहाँ सभी संदिग्ध स्थानों की सूची दी गई है:

• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। संपत्ति। क्रैक 364
• V601 'सत्य' मान को पूर्णांक प्रकार में डाला जाता है। संपत्ति .pp 464
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। PIGCSControllerCom.cpp 405
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। प्रीकॉप 778
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। पहले
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। २३१३ से पहले
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। 23.c22 से पहले
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। SutterLambda.cpp 190
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। SutterLambda.cpp 269
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। सटरलम्बडा। सीपी 285
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। Tofra.cpp 900
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। टोफ्रा। सीपी 1806
• V601 'गलत' मान को पूर्णांक प्रकार में डाला जाता है। Tofra.cpp 1830

अजीब मिलता है

 int pgFocus::GetOffset(double& offset) { MM_THREAD_GUARD_LOCK(&mutex); deviceInfo_.offset = offset; MM_THREAD_GUARD_UNLOCK(&mutex); return DEVICE_OK; } 

यह मुझे लगता है, या इस कोड के साथ कुछ गलत है?

विश्लेषक को यह कोड पसंद नहीं है: V669 'ऑफ़सेट' तर्क एक गैर-स्थिर संदर्भ है। विश्लेषक उस स्थिति को निर्धारित करने में असमर्थ है जिस पर यह तर्क संशोधित किया जा रहा है। यह संभव है कि फ़ंक्शन में कोई त्रुटि है। pgFocus.cpp 356

और वास्तव में, यह अजीब है। फ़ंक्शन को "गेटएटी" कहा जाता है। फ़ंक्शन स्थिति लौटाता है। वह संदर्भ द्वारा 'ऑफसेट' तर्क भी लेता है। और ... और इसमें कुछ भी नहीं लिखा है। मुझे नहीं पता कि यह सब कैसे काम करता है। लेकिन शायद इसके विपरीत असाइनमेंट करना आवश्यक था? कुछ इस तरह:

 offset = deviceInfo_.offset; 

एक और संदिग्ध GetTransmission () फ़ंक्शन:

 int SpectralLMM5Interface::GetTransmission(...., double& transmission) { .... int16_t tr = 0; memcpy(&tr, answer + 1, 2); tr = ntohs(tr); transmission = tr/10; .... } 

PVS-Studio चेतावनी: V636 'tr / 10' की अभिव्यक्ति को 'int' प्रकार से 'डबल' प्रकार में निहित किया गया था। एक आंशिक भाग के नुकसान से बचने के लिए एक स्पष्ट प्रकार के कलाकारों का उपयोग करने पर विचार करें। एक उदाहरण: डबल ए = (डबल) (एक्स) / वाई ;; स्पेक्ट्रलएमएम 5 इन्टरफेस.कपी 198

कृपया ध्यान दें कि वापसी मूल्य डबल प्रकार का है (हम ट्रांसमिशन के बारे में बात कर रहे हैं)। लेकिन इस मूल्य की गणना अजीब तरह से की जाती है। पूर्णांक मान को 10 से विभाजित किया गया है। मेरे पास एक मजबूत संदेह है कि सटीकता का नुकसान है। उदाहरण के लिए, यदि 'tr' 5 है, तो विभाजन के बाद हमें 0 मिलता है, 0.5 बिल्कुल नहीं।

संभवतः सही कोड इस तरह दिखना चाहिए:

 transmission = tr/10.0; 

त्रुटि या कोई त्रुटि? पहली धारणा धोखा दे सकती है।

सी / सी ++ में, शून्य से शुरू होने वाले नंबरों को अष्टक प्रारूप में दिया गया माना जाता है। ΜManager परियोजना में एक संदिग्ध जगह है:

 int LeicaDMSTCHub::StopXY(MM::Device& device, MM::Core& core) { int ret = SetCommand(device, core, xyStage_, 010); if (ret != DEVICE_OK) return ret; return DEVICE_OK; } 

PVS-Studio चेतावनी: V536 सलाह दी जाती है कि उपयोग किए गए स्थिर मान को एक अष्टक रूप द्वारा दर्शाया जाए। अक्टूबर: 010, दिसंबर: 8. LeicaDMSTCHub.cpp 142

यह स्पष्ट नहीं है कि वे वास्तव में 8 नंबर का उपयोग करना चाहते थे, जो अष्टक प्रारूप में लिखे गए थे, या यह एक गलती है। अन्यत्र, दशमलव में लिखी संख्याएँ SetCommand () फ़ंक्शन में पास की जाती हैं। उदाहरण के लिए, इस तरह:

 int ret = SetCommand(device, core, xyStage_, 35, ack); 

मुझे नहीं पता कि कोई त्रुटि मिली या नहीं, लेकिन यह इस स्थान के बारे में ध्यान देने योग्य है।

पूर्णतावादी निरंकुश होता है

वहाँ छोटी चीजें हैं जो महत्वपूर्ण नहीं हैं। हालांकि, लगभग सभी प्रोग्रामर पूर्णतावादी हैं। चलो बड़बड़ाते हैं।

अतिरिक्त लाइनों से भरा हुआ। एक उदाहरण:

 int XYStage::OnTriggerEndX(MM::PropertyBase* pProp, MM::ActionType eAct){ if (eAct == MM::BeforeGet) { int ret = GetCommandValue("trgse",xChannel_,chx_.trgse_); if (ret!=DEVICE_OK) if (ret!=DEVICE_OK) return ret; ..... } 

दूसरी जाँच स्पष्ट रूप से अतिश्योक्तिपूर्ण है।

एक और उदाहरण:

 int AFC::Initialize() { int ret = DEVICE_OK; .... if (ret != DEVICE_OK) return ret; AddAllowedValue("DichroicMirrorIn", "0", 0); AddAllowedValue("DichroicMirrorIn", "1", 1); if (ret != DEVICE_OK) return ret; .... } 

दूसरा चेक फिर से कोई मतलब नहीं है। इससे पहले, चर 'रिट' कहीं भी नहीं बदलेगा। दूसरा परीक्षण सुरक्षित रूप से हटाया जा सकता है।

ऐसे बहुत सारे अतिरिक्त चेक हैं। मुझे उन्हें एक सूची दें: माइक्रो-प्रबंधक- V571-V649.txt ।

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

 int MP285Ctrl::Initialize() { .... unsigned int nUm2UStepUnit = MP285::Instance()->GetUm2UStep(); .... sprintf(sUm2UStepUnit, "%d", nUm2UStepUnit); .... } 

ऐसे तीन स्थान थे:

• V576 गलत प्रारूप। 'स्प्रिंटफ' फ़ंक्शन के तीसरे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। MP285Ctrl.cpp 253
• V576 गलत प्रारूप। 'स्प्रिंटफ' फ़ंक्शन के तीसरे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। MP285Ctrl.cpp 276
• V576 गलत प्रारूप। 'स्प्रिंटफ' फ़ंक्शन के तीसरे वास्तविक तर्क की जाँच करने पर विचार करें। हस्ताक्षर पूर्णांक प्रकार तर्क अपेक्षित है। MP285Ctrl.cpp 327

निष्कर्ष

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

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

छोटी टीमों और व्यक्तिगत डेवलपर्स के लिए, हम CppCat टूल प्रदान करते हैं। व्यक्तिगत लाइसेंस - $ 250। नवीकरण - $ 200। कई लाइसेंस खरीदते समय - छूट।

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

पुनश्च

इस लेख का अनुवाद: " द यूनिकॉर्न ट्रैवल टू द माइक्रोकॉसम "।