👈🏿 👱 🐣 पीवीएस-स्टूडियो स्थैतिक विश्लेषक के साथ न्यूटन गेम डायनेमिक्स रीचेकिंग 🕺 👩🏿‍🚀 👩🏾‍✈️

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

विश्लेषक उत्पादन

2014 में, PVS-Studio ने जारी किया:

48 पहले स्तर के अलर्ट;
79 दूसरे स्तर;
261 तीसरे स्तर।

2020 के लिए, हालांकि:

124 प्रथम स्तर की चेतावनी;
272 दूसरे स्तर;
तीसरे स्तर के 787 (जिनमें दिलचस्प भी हैं)।

एंड्री के लेख की तुलना में बहुत अधिक दिलचस्प चेतावनी है, लेकिन हम उन्हें और अधिक विस्तार से अध्ययन करेंगे ।

चेतावनियों का विवरण

चेतावनी N1

V519 'tmp [i] [2]' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 468, 469. dgCollisionConvexHull.cpp 469

bool dgCollisionConvexHull::Create (dgInt32 count,....)
{
  ....
  dgStack<dgVector> tmp(3 * count);
  for (dgInt32 i = 0; i < count; i ++) 
  {
    tmp[i][0] = dgFloat32 (buffer[i*3 + 0]);
    tmp[i][1] = dgFloat32 (buffer[i*3 + 1]);
    tmp[i][2] = dgFloat32 (buffer[i*3 + 2]);
    tmp[i][2] = dgFloat32 (0.0f);
  }
  ....
}

सरणी तत्व tmp [i] [2] एक पंक्ति में दो बार आरंभीकृत किया जाता है। सबसे अधिक बार, ऐसा कोड कॉपी-पेस्ट की बात करता है। यदि यह आवश्यक नहीं है, तो आप अनावश्यक इनीशियलाइज़ेशन को हटाकर या बाद के एरे इंडेक्स को बदलकर इसे ठीक कर सकते हैं - यह पहले से ही काउंट चर के मूल्य पर निर्भर करता है । इसके बाद, मैं एक और चेतावनी V519 का वर्णन करना चाहूंगा , जो आंद्रेई के लेख में नहीं है, लेकिन हमारे त्रुटि डेटाबेस में है :

V519 'नम' ऑब्जेक्ट को क्रमिक रूप से दो बार मान असाइन किया गया है। शायद यह एक गलती है। भौतिकी dgbody.cpp 404

void dgBody::AddBuoyancyForce (....)
{
  ....
  damp = (m_omega % m_omega) * dgFloat32 (10.0f) *
        fluidAngularViscousity; 
  damp = GetMax (GetMin ((m_omega % m_omega) * 
       dgFloat32 (1000.0f) * 
       fluidAngularViscousity, dgFloat32(0.25f)), 
       dgFloat32(2.0f));
  ....
}

मैं मानता हूं, मुझे यह त्रुटि विश्लेषक लॉग में नहीं मिली। इसके अलावा, मैं भी नहीं मिला AddBuoyancyForce समारोह में dgbody.cpp । यह सामान्य है: यदि हमारे विश्लेषक की चेतावनियों का उपयोग करते हुए पाई गई त्रुटियों के नए उदाहरण पीवीएस-स्टूडियो के विकास का एक संकेतक हैं, तो परियोजना में पहले पाई गई त्रुटियों का अभाव परियोजना के विकास का एक संकेतक है।

एक छोटा सा

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

विश्लेषक ने इस कोड के टुकड़े के लिए दो चेतावनी जारी की:

V621 'ऑपरेटर' के लिए निरीक्षण करने पर विचार करें। यह संभव है कि लूप को गलत तरीके से निष्पादित किया जाएगा या बिल्कुल भी निष्पादित नहीं किया जाएगा। MultiBodyCar.cpp 942

V654 लूप की स्थिति 'i <count' हमेशा झूठी होती है। MultiBodyCar.cpp 942

void MultibodyBodyCar(DemoEntityManager* const scene)
{
  ....
  int count = 10;
  count = 0;
  for (int i = 0; i < count; i++) 
  {
    for (int j = 0; j < count; j++) 
    {
      dMatrix offset(location);
      offset.m_posit += dVector (j * 5.0f + 4.0f, 0.0f, i * 5.0f, 0.0f);
      //manager->CreateSportCar(offset, viperModel.GetData());
      manager->CreateOffRoadCar(offset, monsterTruck.GetData());
    }
  }
  ....
}

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

V519 'रेट' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। लाइनों की जांच करें: 325, 326। dString.cpp 326

void dString::LoadFile (FILE* const file)
{
  ....
  size_t ret = fread(m_string, 1, size, file);
  ret = 0;
  ....
}

V519 'रेट' वेरिएबल को क्रमिक रूप से दो बार मान असाइन किया गया है। यह एक गलती है। जाँच लाइनें: 1222, 1223

void DemoEntityManager::DeserializeFile (....)
{
  ....
  size_t ret = fread(buffer, size, 1, (FILE*) serializeHandle);
  ret = 0;
  ....
}

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: (गणना <10)। dMathDefines.h 726

bool dCholeskyWithRegularizer(....)
{
  ....
  int count = 0;
  while (!pass && (count < 10))
  {
    ....
  }
  ....
}

V654 लूप की स्थिति 'ptr! = Edge' हमेशा झूठी होती है। dgPolyhedra.cpp 1571

void dgPolyhedra::Triangulate (....)
{
  ....
  ptr = edge;
  ....
  while (ptr != edge);
  ....
}

V763 पैरामीटर 'काउंट' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। ConvexCast.cpp 31

StupidComplexOfConvexShapes (...., int count)
{
  count = 40;
  //count = 1;
  ....
}

V547 एक्सप्रेशन 'एक्सिसाउंट' हमेशा गलत होता है। MultiBodyCar.cpp 650

void UpdateDriverInput(dVehicle* const vehicle, dFloat timestep) 
{
  ....
  int axisCount = scene->GetJoystickAxis(axis);
  axisCount = 0;
  if (axisCount)
  {
    ....
  }
  ....
}

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

चेतावनी N2

V769 'परिणाम + i' अभिव्यक्ति में सूचक परिणाम nullptr के बराबर है। परिणामी मूल्य संवेदनहीन है और इसका उपयोग नहीं किया जाना चाहिए। win32_monitor.c 286

GLFWvidmode* _glfwPlatformGetVideoModes(_GLFWmonitor* monitor, int* count)
{
  GLFWvidmode* result = NULL;
  ....
  for (i = 0;  i < *count;  i++)
    {
    if (_glfwCompareVideoModes(result + i, &mode) == 0)
      break;
    }
}

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

चेतावनी N3, N4, N5

V778 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'm_colorChannel' के बजाय 'm_colorChannel' चर का उपयोग किया जाना चाहिए। dgMeshEffect1.cpp 1887

void dgMeshEffect::EndBuildFace ()
{
  ....
  if (m_attrib.m_binormalChannel.m_count) <=
  {
    attibutes.m_binormalChannel.
      PushBack(m_attrib.m_binormalChannel[m_constructionIndex + i]);
  }
  if (m_attrib.m_binormalChannel.m_count) <= 
  {
    attibutes.m_colorChannel.
      PushBack(m_attrib.m_colorChannel[m_constructionIndex + i]);
  }
}

ऐसा लगता है कि प्रोग्रामर ने दो शर्तों की नकल की है। दूसरे को इस तरह दिखना चाहिए:

if (m_attrib.m_colorChannel.m_count) <= 
{
  attibutes.m_colorChannel.
  PushBack(m_attrib.m_colorChannel[m_constructionIndex + i]);
}

इसी तरह की एक और त्रुटि भी मिली:

V524 यह अजीब है कि 'EnabledAxis1' फ़ंक्शन का शरीर 'EnabledAxis0' फ़ंक्शन के शरीर के पूरी तरह से समकक्ष है। dCustomDoubleHingeActuator.cpp 88

void dCustomDoubleHingeActuator::EnabledAxis0(bool state)
{
  m_axis0Enable = state;  <=
}
void dCustomDoubleHingeActuator::EnabledAxis1(bool state)
{
  m_axis0Enable = state;  <=
}

यहां कोड इस तरह तय किया जाना चाहिए:

void dCustomDoubleHingeActuator::EnabledAxis1(bool state)
{
  m_axis1Enable = state;
}

एक और कॉपी-पेस्ट:

V525 कोड में समान ब्लॉकों का संग्रह होता है। 73, 74, 75 लाइनों में 'm_x', 'm_y', 'm_y' चेक करें। dWoodFracture.cpp 73

WoodVoronoidEffect(....)
{
  ....
  for (int i = 0; i < count; i ++) 
  {
    dFloat x = dGaussianRandom(size.m_x * 0.1f);
    dFloat y = dGaussianRandom(size.m_y * 0.1f);  <=
    dFloat z = dGaussianRandom(size.m_y * 0.1f);  <=
  ....
  }
  ....
}

सबसे अधिक संभावना है, चर z की शुरुआत इस तरह दिखनी चाहिए:

dFloat z = dGaussianRandom(size.m_z * 0.1f);

चेतावनियाँ N6, N7

इन न्यूटन गेम डायनेमिक्स, जैसा कि लगभग किसी भी बड़े C या C ++ प्रोजेक्ट में होता है, पॉइंटर्स के साथ असुरक्षित काम के बारे में कुछ चेतावनियाँ थीं। ऐसी त्रुटियों को खोजने और डिबग करने में अक्सर बहुत मुश्किल होती है; वे प्रोग्राम क्रैश का कारण बनते हैं; सामान्य तौर पर, वे बहुत खतरनाक और अप्रत्याशित होते हैं। सौभाग्य से, हमारा विश्लेषक इनमें से कई त्रुटियों का पता लगाने में सक्षम है। यह स्पष्ट प्रतीत होता है कि चेक को एक बार लिखना और स्टीम बाथ न लेना बेहतर है, समस्या को पुन: उत्पन्न करने में बहुत समय बिताने के बजाय, कोड में समस्या का स्थान ढूंढना और उसे डीबग करना। यहाँ कुछ चेतावनियाँ दी गई हैं:

V522 एक संभावित अशक्त पॉइंटर 'फेस' की डीफ्रेंसिंग हो सकती है। dgContactSolver.cpp 351

DG_INLINE dgMinkFace* dgContactSolver::AddFace(dgInt32 v0,dgInt32 v1,
                                               dgInt32 v2)
{
  dgMinkFace* const face = NewFace();
  face->m_mark = 0; 
  ....
}

न्यूफ़ास फ़ंक्शन की परिभाषा छोटी है, इसलिए मैं इसे पूर्ण रूप से दूंगा:

DG_INLINE dgMinkFace* dgContactSolver::NewFace()
{
  dgMinkFace* face = (dgMinkFace*)m_freeFace;
  if (m_freeFace) 
  {
    m_freeFace = m_freeFace->m_next;
  } else 
  {
    face = &m_facePool[m_faceIndex];
    m_faceIndex++;
    if (m_faceIndex >= DG_CONVEX_MINK_MAX_FACES) 
    {
      return NULL;
    }
  }
#ifdef _DEBUG
    memset(face, 0, sizeof (dgMinkFace));
#endif
  return face;
}

एग्ज़िट पॉइंट्स में से एक फंक्शन न्यूफ़ेस , NULL को लौटाता है , अगर नेल पॉइंटर डेरेफ़रिंग वापस आती है और प्रोग्राम का अपरिभाषित व्यवहार होगा।

कोड के अधिक खतरनाक टुकड़े के लिए भी इसी तरह की चेतावनी दी गई है:

V522 एक संभावित अशक्त सूचक 'परिधि' की डीफ्रेंसिंग हो सकती है। dgPolyhedra.cpp 2541

bool dgPolyhedra::PolygonizeFace(....)
{
  ....
  dgEdge* const perimeter = flatFace.AddHalfEdge
                           (edge1->m_next->m_incidentVertex,
                            edge1->m_incidentVertex);
  perimeter->m_twin = edge1;
  ....
}

यहां AddHalfEdge की परिभाषा दी गई है :

dgEdge* dgPolyhedra::AddHalfEdge (dgInt32 v0, dgInt32 v1)
{
  if (v0 != v1) 
  {
    dgPairKey pairKey (v0, v1);
    dgEdge tmpEdge (v0, -1);
    dgTreeNode* node = Insert (tmpEdge, pairKey.GetVal()); 
    return node ? &node->GetInfo() : NULL;
  } else 
  {
    return NULL;
  }
}

यहां, NULL फ़ंक्शन के तीन संभावित निकास बिंदुओं के दो बिंदुओं पर वापसी मूल्य है।

कुल मिलाकर, मुझे 48 वी 522 चेतावनी मिली । अधिकांश भाग के लिए, वे एक ही प्रकार के होते हैं, इसलिए मुझे इस लेख के ढांचे में किसी भी अधिक का वर्णन करने का कोई कारण नहीं दिखता है।

चेतावनी N8

V668 नल के खिलाफ 'pBits' पॉइंटर के परीक्षण में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। TargaToOpenGl.cpp 166

char* const pBits = new char [width * height * 4];
if(pBits == NULL) 
{
  fclose(pFile);
  return 0;
}

विश्लेषक ने एक ऐसी स्थिति का पता लगाया जहां नए ऑपरेटर द्वारा लौटाए गए पॉइंटर का मूल्य शून्य की तुलना में है। एक नियम के रूप में, इसका मतलब है कि कार्यक्रम, यदि मेमोरी को आवंटित करना असंभव है, तो प्रोग्रामर अपेक्षा से अलग व्यवहार करेगा। यदि नया ऑपरेटर मेमोरी आवंटित नहीं कर सका, तो, C ++ भाषा मानक के अनुसार , एक अपवाद std :: bad_alloc () फेंका गया है। इस प्रकार, शर्त कभी पूरी नहीं होगी। यह स्पष्ट रूप से व्यवहार नहीं है जो प्रोग्रामर पर भरोसा कर रहा था। उन्होंने मेमोरी आवंटन त्रुटि के मामले में फ़ाइल को बंद करने की योजना बनाई। ऐसा नहीं होगा और रिसोर्स लीक होगा।

चेतावनी एन 9, एन 10, एन 11

V764 he CreateWheel ’फ़ंक्शन: P ऊँचाई’ और ius त्रिज्या ’के लिए दिए गए तर्कों का संभावित गलत क्रम। StandardJoints.cpp 791
V764 he CreateWheel ’फ़ंक्शन: and ऊँचाई’ और ius त्रिज्या ’को पारित किए गए तर्कों का संभावित गलत क्रम। StandardJoints.cpp 833
V764 he CreateWheel ’फ़ंक्शन: P ऊँचाई’ और ius त्रिज्या ’के लिए दिए गए तर्कों का संभावित गलत क्रम। StandardJoints.cpp 884

इस प्रकार फ़ंक्शन कॉल दिखता है:

NewtonBody* const wheel = CreateWheel (scene, origin, height, radius);

इस तरह से फ़ंक्शन की घोषणा दिखती है:

static NewtonBody* CreateWheel (DemoEntityManager* const scene,
  const dVector& location, dFloat radius, dFloat height)

इस निदान से पता चलता है कि जब कॉलिंग फ़ंक्शन, शायद तर्कों को मिलाया गया था।

चेतावनियाँ N12, N13

विश्लेषक ने अलग-अलग नामों से दो समान विधियों के लिए चेतावनी जारी की:

V621 'ऑपरेटर' के निरीक्षण पर विचार करें। यह संभव है कि लूप को गलत तरीके से निष्पादित किया जाएगा या बिल्कुल भी निष्पादित नहीं किया जाएगा। dgCollisionUserMesh.cpp 161

V621 'ऑपरेटर' के लिए निरीक्षण करने पर विचार करें। यह संभव है कि लूप को गलत तरीके से निष्पादित किया जाएगा या बिल्कुल भी निष्पादित नहीं किया जाएगा। dgCollisionUserMesh.cpp 236

void dgCollisionUserMesh::GetCollidingFacesContinue
    (dgPolygonMeshDesc* const data) const
{
  ....
  data->m_faceCount = 0; <=
  data->m_userData = m_userData;
  data->m_separationDistance = dgFloat32(0.0f);
  m_collideCallback(&data->m_p0, NULL);
  dgInt32 faceCount0 = 0;
  dgInt32 faceIndexCount0 = 0;
  dgInt32 faceIndexCount1 = 0;
  dgInt32 stride = data->m_vertexStrideInBytes / sizeof(dgFloat32);
  dgFloat32* const vertex = data->m_vertex;
  dgInt32* const address = data->m_meshData.m_globalFaceIndexStart;
  dgFloat32* const hitDistance = data->m_meshData.m_globalHitDistance;
  const dgInt32* const srcIndices = data->m_faceVertexIndex;
  dgInt32* const dstIndices = data->m_globalFaceVertexIndex;
  dgInt32* const faceIndexCountArray = data->m_faceIndexCount;
  for (dgInt32 i = 0; (i < data->m_faceCount)&&
       (faceIndexCount0 < (DG_MAX_COLLIDING_INDICES - 32));
       i++)
  {
    ....
  }
  ....
}
void dgCollisionUserMesh::GetCollidingFacesDescrete
    (dgPolygonMeshDesc* const data) const
{
  ....
  data->m_faceCount = 0; <=  
  data->m_userData = m_userData;
  data->m_separationDistance = dgFloat32(0.0f);
  m_collideCallback(&data->m_p0, NULL);
  dgInt32 faceCount0 = 0;
  dgInt32 faceIndexCount0 = 0;
  dgInt32 faceIndexCount1 = 0;
  dgInt32 stride = data->m_vertexStrideInBytes / sizeof(dgFloat32);
  dgFloat32* const vertex = data->m_vertex;
  dgInt32* const address = data->m_meshData.m_globalFaceIndexStart;
  dgFloat32* const hitDistance = data->m_meshData.m_globalHitDistance;
  const dgInt32* const srcIndices = data->m_faceVertexIndex;
  dgInt32* const dstIndices = data->m_globalFaceVertexIndex;
  dgInt32* const faceIndexCountArray = data->m_faceIndexCount;
  for (dgInt32 i = 0; (i < data->m_faceCount)&&
       (faceIndexCount0 < (DG_MAX_COLLIDING_INDICES - 32));
       i++)
  {
    ....
  }
  ....
}

स्थिति के इस भाग में समस्या यह है: i <data-> m_faceCount। चूंकि डेटा-> m_faceCount 0 को असाइन किया गया है, इस लूप को एक बार भी निष्पादित नहीं किया जाएगा। शायद, जब कोड के इस टुकड़े को लिखना, प्रोग्रामर m_faceCount फ़ील्ड को फिर से बनाना भूल गया , और फिर बस विधि बॉडी की प्रतिलिपि बनाई।

चेतावनी N14, N15

विश्लेषक ने उत्तराधिकार में कोड की समान पंक्तियों के लिए दो चेतावनियाँ जारी की:

V630 '_alloca' फ़ंक्शन का उपयोग ऑब्जेक्ट की एक सरणी के लिए मेमोरी आवंटित करने के लिए किया जाता है जो निर्माणकर्ता हैं। dgSkeletonContainer.cpp 1341

V630 '_alloca' फ़ंक्शन का उपयोग उन ऑब्जेक्ट्स की एक सरणी के लिए मेमोरी आवंटित करने के लिए किया जाता है जो निर्माणकर्ता हैं। dgSkeletonContainer.cpp 1342

#define alloca _alloca
....
#define dAlloca(type,size) (type*) alloca ((size) * sizeof (type))
....
dgSpatialMatrix::dgSpatialMatrix();
dgSpatialMatrix::dgSpatialMatrix(dgFloat32 val);
....
dgSpatialMatrix* const bodyMassArray = dgAlloca(dgSpatialMatrix,
                                                m_nodeCount);
dgSpatialMatrix* const jointMassArray = dgAlloca(dgSpatialMatrix,
                                                 m_nodeCount);

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

V630 The '_alloca' function is used to allocate memory for an array of objects which are classes containing constructors. dVehicleSolver.cpp 498
V630 The '_alloca' function is used to allocate memory for an array of objects which are classes containing constructors. dVehicleSolver.cpp 499
V630 The '_alloca' function is used to allocate memory for an array of objects which are classes containing constructors. dVehicleSolver.cpp 1144
10 .

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

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

पीवीएस-स्टूडियो स्थैतिक विश्लेषक के साथ न्यूटन गेम डायनेमिक्स रीचेकिंग

विश्लेषक उत्पादन

चेतावनियों का विवरण

More articles: