पीवीएस-स्टूडियो ने रेड डेड रिडेम्पशन इंजन - बुलेट पर नज़र रखी

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

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

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

वार्मिंग के लिए

उदाहरण 1:

आइए एक अजीब गलती से शुरू करें:

V624 '3.141592538' स्थिरांक में एक गलत धारणा है। <Math.h> से M_PI स्थिरांक का उपयोग करने पर विचार करें। PhysicsClientC_API.cpp 4109

B3_SHARED_API void b3ComputeProjectionMatrixFOV(float fov, ....) { float yScale = 1.0 / tan((3.141592538 / 180.0) * fov / 2); .... } 

संख्या पाई (3.141592653 ...) में एक छोटा टाइपो, फ्रैक्चर भाग में 7 वें स्थान पर "6" नंबर गायब है।

शायद दस-दसवें दशमलव स्थान में त्रुटि मूर्त परिणाम नहीं देगी, लेकिन आपको अभी भी बिना लायब्रेरी के मौजूदा लाइब्रेरी स्थिरांक का उपयोग करना चाहिए। Pi के लिए, math.h शीर्ष लेख से M_PI स्थिरांक है।

कॉपी पेस्ट करें

उदाहरण 2:

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

V751 पैरामीटर 'halfExtentsZ' का उपयोग फ़ंक्शन बॉडी के अंदर नहीं किया जाता है। TinyRenderer.cpp 375

 void TinyRenderObjectData::createCube(float halfExtentsX, float halfExtentsY, float halfExtentsZ, ....) { .... m_model->addVertex(halfExtentsX * cube_vertices_textured[i * 9], halfExtentsY * cube_vertices_textured[i * 9 + 1], halfExtentsY * cube_vertices_textured[i * 9 + 2], cube_vertices_textured[i * 9 + 4], ....); .... } 

उदाहरण 3:

विश्लेषक ने निम्नलिखित दिलचस्प टुकड़ा भी पाया, मैं इसे अपने मूल रूप में पहले लाऊंगा।


यह अंतिम पंक्ति देखें?


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

विश्लेषक ने इस लाइन पर निम्नलिखित चेतावनी जारी की।

V501 समान उप-अभिव्यक्तियाँ हैं 'रोटैट.कॉल्यूमेंट 1 ()। नॉर्म () <1.0001' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। LinearR4.cpp 351

V501 समान उप-अभिव्यक्तियाँ हैं '0.9999 <rotmat.Column1 ()। Norm ()' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। LinearR4.cpp 351

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

  Column1().Norm() < 1.0001 && 0.9999 < Column1().Norm() && Column1().Norm() < 1.0001 && 0.9999 < Column1().Norm() &&(Column1() ^ Column2()) < 0.001 && (Column1() ^ Column2()) > -0.001 

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

उदाहरण 4:

इसी तरह की त्रुटि:

V501 समान उप-अभिव्यक्तियाँ हैं 'cs.m_fJacCoeffInv [0] == 0' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। b3CpuRigidBodyPipeline.cpp 169

 float m_fJacCoeffInv[2]; static inline void b3SolveFriction(b3ContactConstraint4& cs, ....) { if (cs.m_fJacCoeffInv[0] == 0 && cs.m_fJacCoeffInv[0] == 0) { return; } .... } 

इस स्थिति में, समान एरे तत्व को डबल चेक किया जाता है। सबसे अधिक संभावना है, स्थिति इस तरह दिखनी चाहिए: cs.m_fJacCoeffInv [0] == 0 && cs.m_fJacCoeffInv [1] == 0 । यह कॉपी-पेस्ट त्रुटि का एक उत्कृष्ट उदाहरण है।

उदाहरण 5:

एक और कमी की खोज की गई थी:

V517 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। जाँच लाइनें: 79, 112. main.cpp 79

 int main(int argc, char* argv[]) { .... while (serviceResult > 0) { serviceResult = enet_host_service(client, &event, 0); if (serviceResult > 0) { .... } else if (serviceResult > 0) { puts("Error with servicing the client"); exit(EXIT_FAILURE); } .... } .... } 

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

एक समान विश्लेषक चेतावनी, जिसका लेख में वर्णन करने का कोई मतलब नहीं है:

V517 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। जाँच लाइनें: 151, 190. PhysicsClientUDP.cpp 151

सीमा से परे: सरणी की सीमाओं से परे जाना

उदाहरण 6:

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

यहां, लूप स्थिति में, डॉफिंडेक्स चर ऊपर से 128 तक सीमित है , और डॉफ 4 से समावेशी है। लेकिन m_desiredState में केवल 128 तत्व शामिल हैं। नतीजतन, सूचकांक [dofIndex + dof] सरणी के बहिर्वाह को जन्म दे सकता है।

V557 ऐरे ओवररन संभव है। 'DofIndex + dof' इंडेक्स का मान 130 तक पहुंच सकता है। PhysicsClientC_API.cpp 968

 #define MAX_DEGREE_OF_FREEDOM 128 double m_desiredState[MAX_DEGREE_OF_FREEDOM]; B3_SHARED_API int b3JointControl(int dofIndex, double* forces, int dofCount, ....) { .... if ( (dofIndex >= 0) && (dofIndex < MAX_DEGREE_OF_FREEDOM ) && dofCount >= 0 && dofCount <= 4) { for (int dof = 0; dof < dofCount; dof++) { command->m_sendState.m_desiredState[dofIndex+dof] = forces[dof]; .... } } .... } 

उदाहरण 7:

इसी तरह की एक त्रुटि, लेकिन अब एक सरणी को अनुक्रमित करने के लिए नहीं बल्कि एक स्थिति में समन की ओर जाता है। यदि फ़ाइल नाम यथासंभव लंबे समय तक है, तो टर्मिनल शून्य को सरणी ( ऑफ-बाय-वन एरर ) के बाहर लिखा जाएगा। स्वाभाविक रूप से, लेन चर केवल असाधारण मामलों में MAX_FILENAME_LENGTH के बराबर होगा, लेकिन यह त्रुटि को समाप्त नहीं करता है, लेकिन बस इसकी घटना को दुर्लभ बनाता है।

V557 ऐरे ओवररन संभव है। 'लेन' सूचकांक का मान 1024 तक पहुंच सकता है। PhysicsClientC_API.cpp 5223

 #define MAX_FILENAME_LENGTH MAX_URDF_FILENAME_LENGTH 1024 struct b3Profile { char m_name[MAX_FILENAME_LENGTH]; int m_durationInMicroSeconds; }; int len = strlen(name); if (len >= 0 && len < (MAX_FILENAME_LENGTH + 1)) { command->m_type = CMD_PROFILE_TIMING; strcpy(command->m_profile.m_name, name); command->m_profile.m_name[len] = 0; } 

उपाय एक बार - सात बार काटें

उदाहरण 8:

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

V807 प्रदर्शन में कमी। 'M_app-> m_renderer-> getActiveCamera () बार-बार अभिव्यक्ति का उपयोग करने से बचने के लिए एक पॉइंटर बनाने पर विचार करें। InverseKinematicsExample.cpp 315

 virtual void resetCamera() { .... if (....) { m_app->m_renderer->getActiveCamera()->setCameraDistance(dist); m_app->m_renderer->getActiveCamera()->setCameraPitch(pitch); m_app->m_renderer->getActiveCamera()->setCameraYaw(yaw); m_app->m_renderer->getActiveCamera()->setCameraPosition(....); } } 

यहां उसी कॉल चेन का पुन: उपयोग किया जाता है, जिसे सिंगल पॉइंटर से बदला जा सकता है।

उदाहरण 9:

V810 प्रदर्शन में कमी। 'BtCos (euler_out.pitch)' फ़ंक्शन को समान तर्कों के साथ कई बार कहा गया था। परिणाम को संभवतः एक अस्थायी चर में सहेजा जाना चाहिए, जिसे तब 'btAtan2' फ़ंक्शन को कॉल करते समय उपयोग किया जा सकता है। btMatrix3x3.h 576

V810 प्रदर्शन में कमी। समान तर्कों के साथ 'btCos (euler_out2.pitch)' समारोह को कई बार बुलाया गया। परिणाम को संभवतः एक अस्थायी चर में सहेजा जाना चाहिए, जिसे तब 'btAtan2' फ़ंक्शन को कॉल करते समय उपयोग किया जा सकता है। btMatrix3x3.h 578

 void getEulerZYX(....) const { .... if (....) { .... } else { .... euler_out.roll = btAtan2(m_el[2].y() / btCos(euler_out.pitch), m_el[2].z() / btCos(euler_out.pitch)); euler_out2.roll = btAtan2(m_el[2].y() / btCos(euler_out2.pitch), m_el[2].z() / btCos(euler_out2.pitch)); euler_out.yaw = btAtan2(m_el[1].x() / btCos(euler_out.pitch), m_el[0].x() / btCos(euler_out.pitch)); euler_out2.yaw = btAtan2(m_el[1].x() / btCos(euler_out2.pitch), m_el[0].x() / btCos(euler_out2.pitch)); } .... } 

इस स्थिति में, आप दो वेरिएबल्स बना सकते हैं और btCos फ़ंक्शन द्वारा दिए गए मानों को euler_out.pitch और euler_out2.pitch में संग्रहीत कर सकते हैं , बजाय फ़ंक्शन को प्रत्येक तर्क के लिए चार बार कॉल कर सकते हैं।

रिसाव

उदाहरण 10:

परियोजना में निम्नलिखित प्रकार की बहुत सी त्रुटियां पाई गईं:

V773 'आयातक' पॉइंटर की दृश्यता का दायरा मेमोरी जारी किए बिना बाहर निकल गया था। एक स्मृति रिसाव संभव है। सीरियलाइज़सैटअप। सीपी 94

 void SerializeSetup::initPhysics() { .... btBulletWorldImporter* importer = new btBulletWorldImporter(m_dynamicsWorld); .... fclose(file); m_guiHelper->autogenerateGraphicsObjects(m_dynamicsWorld); } 

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

यहां आपके कानून हैं

उदाहरण 11:

निम्नलिखित त्रुटि कोड में इस तथ्य के कारण दिखाई देती है कि C ++ नियम हमेशा गणितीय नियमों या "सामान्य ज्ञान" के साथ मेल नहीं खाते हैं। अपने लिए नोटिस जहां त्रुटि कोड के एक छोटे से स्निपेट में है?

 btAlignedObjectArray<btFractureBody*> m_fractureBodies; void btFractureDynamicsWorld::fractureCallback() { for (int i = 0; i < numManifolds; i++) { .... int f0 = m_fractureBodies.findLinearSearch(....); int f1 = m_fractureBodies.findLinearSearch(....); if (f0 == f1 == m_fractureBodies.size()) continue; .... } .... } 

विश्लेषक निम्नलिखित चेतावनी उत्पन्न करता है:

V709 संदिग्ध तुलना में पाया गया: 'f0 == f1 == m_fractureBodies.size ()'। याद रखें कि 'a == b == c' 'a == b && b == c' के बराबर नहीं है। btFractureDynamicsWorld.cpp 483

ऐसा लगता है कि हालत की जाँच करता है कि f0 f1 के बराबर है और m_fractureBodies में तत्वों की संख्या के बराबर है। ऐसा लगता है कि इस तुलना की जाँच होनी चाहिए अगर f0 और f1 m_fractureBodies सरणी के अंत में हैं, क्योंकि वे findLinearSearch () विधि द्वारा पाई गई वस्तु की स्थिति को समाहित करते हैं। हालाँकि, वास्तव में, यह अभिव्यक्ति यह देखने के लिए चेक में बदल जाती है कि क्या f0 और f1 समान हैं, और फिर m_fractureBodies.size () f0 == f1 के परिणाम के बराबर है या नहीं। नतीजतन, तीसरे ऑपरेंड की तुलना यहां 0 या 1 के साथ की जाती है।

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

उदाहरण 12:

स्ट्रिंग्स के साथ काम करते समय, अक्सर स्ट्रिंग क्लास द्वारा प्रदान की जाने वाली सुविधाओं का उपयोग करना बेहतर होता है। तो, निम्नलिखित दो मामलों के लिए , क्रमशः MyStr.length () और val.clear () के साथ strlen (MyStr.c_str ()) और val = "" को बदलना बेहतर है।

V806 प्रदर्शन में कमी। Strlen (MyStr.c_str ()) तरह के अभिव्यक्ति को MyStr.length () के रूप में फिर से लिखा जा सकता है। RobotLoggingUtil.cpp 213

 FILE* createMinitaurLogFile(const char* fileName, std::string& structTypes, ....) { FILE* f = fopen(fileName, "wb"); if (f) { .... fwrite(structTypes.c_str(), strlen(structTypes.c_str()), 1, f); .... } .... } 

V815 प्रदर्शन में कमी। 'Val.clear ()' के साथ 'val = "" "की जगह पर विचार करें। b3CommandLineArgs.h 40

 void addArgs(int argc, char **argv) { .... std::string val; .... val = ""; .... } 

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

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

हमारे सामने त्रुटियां पाई गईं

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

रिपॉजिटरी में बहुत सारे पुल अनुरोध नहीं थे, और उनमें से कई इंजन के आंतरिक तर्क से संबंधित हैं। लेकिन ऐसी त्रुटियां भी थीं जो विश्लेषक का पता लगा सकते थे।

उदाहरण 13:

 char m_deviceExtensions[B3_MAX_STRING_LENGTH]; void b3OpenCLUtils_printDeviceInfo(cl_device_id device) { b3OpenCLDeviceInfo info; b3OpenCLUtils::getDeviceInfo(device, &info); .... if (info.m_deviceExtensions != 0) { .... } } 

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

V600 स्थिति का निरीक्षण करने पर विचार करें। 'Info.m_deviceExtensions' पॉइंटर हमेशा NULL के बराबर नहीं होता है। b3OpenCLUtils.cpp 551

उदाहरण 14:

क्या आप तुरंत पता लगा सकते हैं कि अगले फ़ंक्शन में क्या समस्या है?

 inline void Matrix4x4::SetIdentity() { m12 = m13 = m14 = m21 = m23 = m24 = m13 = m23 = m41 = m42 = m43 = 0.0; m11 = m22 = m33 = m44 = 1.0; } 

विश्लेषक निम्नलिखित चेतावनी देता है:

V570 समान मान दो बार 'm23' चर को सौंपा गया है। लीनियर 4.एच 627

V570 एक ही मान 'm13' चर के लिए दो बार सौंपा गया है। लीनियर ४.एच ६२h

रिकॉर्डिंग के इस रूप के साथ बार-बार असाइनमेंट को नग्न आंखों से ट्रैक करना मुश्किल होता है और परिणामस्वरूप, कुछ मैट्रिक्स तत्वों को प्रारंभिक मूल्य प्राप्त नहीं हुआ। यह त्रुटि असाइनमेंट रिकॉर्ड के सारणीबद्ध रूप में ठीक की गई थी:

 m12 = m13 = m14 = m21 = m23 = m24 = m31 = m32 = m34 = m41 = m42 = m43 = 0.0; 

उदाहरण 15:

BtSoftBody की शर्तों में से एक में निम्न त्रुटि :: addAeroForceToNode () फ़ंक्शन एक स्पष्ट बग के लिए नेतृत्व किया। पुल अनुरोध में टिप्पणी के अनुसार, बलों को गलत पक्ष से वस्तुओं पर लागू किया गया था।

 struct eAeroModel { enum _ { V_Point, V_TwoSided, .... END }; }; void btSoftBody::addAeroForceToNode(....) { .... if (....) { if (btSoftBody::eAeroModel::V_TwoSided) { .... } .... } .... } 

PVS- स्टूडियो भी इस त्रुटि को पा सकता है और निम्नलिखित चेतावनी प्रदर्शित कर सकता है:

V768 एन्यूमरेशन स्थिरांक 'V_TwoSided' का उपयोग बूलियन-प्रकार के एक चर के रूप में किया जाता है। btSoftBody.cpp 542

सही किया गया चेक इस प्रकार है:

 if (m_cfg.aeromodel == btSoftBody::eAeroModel::V_TwoSided) { .... } 

एन्यूमरेटर्स में से किसी एक को ऑब्जेक्ट प्रॉपर्टी की समतुल्यता के बजाय, V_TwoSered एन्यूमरेटर को ही चेक किया गया था।

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

निष्कर्ष

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

यदि आप हमेशा हमारी टीम की खबरों और घटनाओं के बारे में जानना चाहते हैं, तो हमारी सामाजिक सेवाओं की सदस्यता लें। नेटवर्क: इंस्टाग्राम , ट्विटर , Vkontakte , टेलीग्राम ।



यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद लिंक का उपयोग करें: PVS-Studio ने रेड डेड रिडेम्पशन के बुलेट इंजन में देखा