और फिर से अंतरिक्ष में: गेंडा स्टेलारियम का दौरा कैसे किया

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

परियोजना के बारे में थोड़ा ...

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

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

... और विश्लेषक के बारे में

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

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

स्टेलेरियम के नए पाठकों और उपयोगकर्ताओं ने सोचा हो सकता है: लेख के शीर्षक में यूनिकॉर्न क्यों दिखाई देता है और यह कोड विश्लेषण से कैसे संबंधित है? मैं जवाब देता हूं: मैं पीवीएस-स्टूडियो के डेवलपर्स में से एक हूं, और गेंडा हमारा पसंदीदा शरारती शुभंकर है। इतना ऊपर!

मुझे उम्मीद है कि इस लेख के लिए धन्यवाद, पाठक खुद के लिए कुछ नया सीखेंगे, और स्टेलारियम डेवलपर्स कुछ त्रुटियों को खत्म करने और कोड की गुणवत्ता में सुधार करने में सक्षम होंगे।

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

संदेहास्पद स्थिति

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

void QZipReaderPrivate::scanFiles() { .... // find EndOfDirectory header int i = 0; int start_of_directory = -1; EndOfDirectory eod; while (start_of_directory == -1) { const int pos = device->size() - int(sizeof(EndOfDirectory)) - i; if (pos < 0 || i > 65535) { qWarning() << "QZip: EndOfDirectory not found"; return; } device->seek(pos); device->read((char *)&eod, sizeof(EndOfDirectory)); if (readUInt(eod.signature) == 0x06054b50) break; ++i; } .... } 

पीवीएस-स्टूडियो चेतावनी : V654 लूप की स्थिति 'start_of_directory == - 1' हमेशा सच होती है। qzip.cpp 617

क्या आपको कोई गलती मिल सकती है? अगर ऐसा है तो तारीफ करें।

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

मुझे ऐसा लगता है कि कोड में वे असाइनमेंट start_of_directory = पॉज़ को उस स्थान पर बनाना भूल गए जहां हस्ताक्षर सत्यापित किया जा रहा है। तब विराम कथन शायद अतिश्योक्तिपूर्ण है। इस मामले में, कोड को इस तरह से फिर से लिखा जा सकता है:

 int i = 0; int start_of_directory = -1; EndOfDirectory eod; while (start_of_directory == -1) { const int pos = device->size() - int(sizeof(EndOfDirectory)) - i; if (pos < 0 || i > 65535) { qWarning() << "QZip: EndOfDirectory not found"; return; } device->seek(pos); device->read((char *)&eod, sizeof(EndOfDirectory)); if (readUInt(eod.signature) == 0x06054b50) start_of_directory = pos; ++i; } 

हालाँकि, मुझे यकीन नहीं है कि कोड क्या होना चाहिए। यह सबसे अच्छा है कि परियोजना डेवलपर्स खुद कार्यक्रम के इस हिस्से का विश्लेषण करें और आवश्यक बदलाव करें।

एक और अजीब स्थिति:

 class StelProjectorCylinder : public StelProjector { public: .... protected: .... virtual bool intersectViewportDiscontinuityInternal(const Vec3d& capN, double capD) const { static const SphericalCap cap1(1,0,0); static const SphericalCap cap2(-1,0,0); static const SphericalCap cap3(0,0,-1); SphericalCap cap(capN, capD); return cap.intersects(cap1) && cap.intersects(cap2) && cap.intersects(cap2); } }; 

PVS-Studio चेतावनी: V501 समान उप-अभिव्यक्तियाँ हैं 'cap.intersects (cap2)' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। StelProjectorClasses.hpp 175

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

इस प्रकार की त्रुटि अत्यंत सामान्य है: लगभग हर परीक्षण परियोजना में, हमें नाम 1 और name2 और इसी तरह के नामों से संबंधित टाइपोस का सामना करना पड़ा है। आमतौर पर, ऐसी त्रुटियां कॉपी-पेस्ट से संबंधित होती हैं।

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

 void BottomStelBar::updateText(bool updatePos) { .... updatePos = true; .... if (location->text() != newLocation || updatePos) { updatePos = true; .... } .... if (fov->text() != str) { updatePos = true; .... } .... if (fps->text() != str) { updatePos = true; .... } if (updatePos) { .... } } 

पीवीएस-स्टूडियो चेतावनी:

• V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: अपडेटपोस। StelGuiItems.cpp 732
• V547 एक्सप्रेशन 'अपडेटपोस' हमेशा सच होता है। StelGuiItems.cpp 831
• V763 पैरामीटर 'अपडेटपोस' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। StelGuiItems.cpp 690

अपडेटपोस पैरामीटर का मान हमेशा उपयोग होने से पहले ही ओवरराइट हो जाता है, अर्थात फ़ंक्शन समान कार्य करेगा, भले ही इसके लिए कोई मान पास न हो।

अजीब लग रहा है, है ना? सभी जगहों पर जहां अपडेटपोस पैरामीटर शामिल है , यह सच है । इसका अर्थ यह है कि यदि स्थितियां (स्थान-> पाठ) (! = NewLocation || updatePos) और यदि (updatePos) हमेशा सही होंगी।

एक और स्निपेट:

 void LandscapeMgr::onTargetLocationChanged(StelLocation loc) { .... if (pl && flagEnvironmentAutoEnabling) { QSettings* conf = StelApp::getInstance().getSettings(); setFlagAtmosphere(pl->hasAtmosphere() & conf->value("landscape/flag_atmosphere", true).toBool()); setFlagFog(pl->hasAtmosphere() & conf->value("landscape/flag_fog", true).toBool()); setFlagLandscape(true); } .... } 

पीवीएस-स्टूडियो चेतावनी:

• V792 ऑपरेटर के दाईं ओर स्थित 'toBool' फ़ंक्शन को बाएं ऑपरेटर के मूल्य की परवाह किए बिना कहा जाएगा। शायद, '&&' का उपयोग करना बेहतर है। लैंडस्केपमग्र्प। .२
• V792 ऑपरेटर के दाईं ओर स्थित 'toBool' फ़ंक्शन को बाएं ऑपरेटर के मूल्य की परवाह किए बिना कहा जाएगा। शायद, '&&' का उपयोग करना बेहतर है। लैंडस्केपमग्र्प। 783

विश्लेषक ने setFlagAt वायुमंडल और setFagagFog कार्यों के तर्कों में एक संदिग्ध अभिव्यक्ति का पता लगाया। वास्तव में: बिट ऑपरेटर के दोनों किनारों पर और प्रकार बूल के मूल्य हैं। & ऑपरेटर के बजाय, आपको && ऑपरेटर का उपयोग करना चाहिए, और अब मैं समझाऊंगा कि क्यों।

हां, इस अभिव्यक्ति का परिणाम हमेशा सही होगा। बिटवाइज “और” का उपयोग करने से पहले, दोनों ऑपरेंड को इंट में पदोन्नत किया जाएगा। C ++ में, ऐसा रूपांतरण असंदिग्ध है : असत्य को 0 में बदल दिया जाता है, और सत्य को 1 में बदल दिया जाता है। इसलिए, इस अभिव्यक्ति का परिणाम उसी तरह होगा जैसे && संचालक का उपयोग किया गया था।

लेकिन एक अति सूक्ष्म अंतर है। && ऑपरेशन के परिणाम की गणना करते समय, तथाकथित "आलसी गणना" का उपयोग किया जाता है। यदि बाएं ऑपरेंड का मूल्य गलत है , तो सही मूल्य की गणना भी नहीं की जाती है, क्योंकि तार्किक "और" किसी भी स्थिति में गलत वापस आ जाएगा। यह कंप्यूटिंग संसाधनों को बचाने के लिए किया जाता है और आपको अधिक जटिल डिजाइन लिखने की अनुमति देता है। उदाहरण के लिए, आप यह सत्यापित कर सकते हैं कि पॉइंटर अशक्त नहीं है, और यदि ऐसा है, तो अतिरिक्त जाँच करने के लिए इसे डिरेल करें। उदाहरण: अगर (ptr && ptr-> foo ()) ।

इस तरह की "आलसी गणना" बिटवाइज ऑपरेटर और : भावों का उपयोग करके नहीं की जाती है।

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

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

हम अगले विषय पर आगे बढ़ते हैं।

गलत मेमोरी हैंडलिंग

आइए इस टुकड़े के साथ गतिशील स्मृति के विषय को शुरू करें:

 /************ Basic Edge Operations ****************/ /* __gl_meshMakeEdge creates one edge, * two vertices, and a loop (face). * The loop consists of the two new half-edges. */ GLUEShalfEdge* __gl_meshMakeEdge(GLUESmesh* mesh) { GLUESvertex* newVertex1 = allocVertex(); GLUESvertex* newVertex2 = allocVertex(); GLUESface* newFace = allocFace(); GLUEShalfEdge* e; /* if any one is null then all get freed */ if ( newVertex1 == NULL || newVertex2 == NULL || newFace == NULL) { if (newVertex1 != NULL) { memFree(newVertex1); } if (newVertex2 != NULL) { memFree(newVertex2); } if (newFace != NULL) { memFree(newFace); } return NULL; } e = MakeEdge(&mesh->eHead); if (e == NULL) { return NULL; } MakeVertex(newVertex1, e, &mesh->vHead); MakeVertex(newVertex2, e->Sym, &mesh->vHead); MakeFace(newFace, e, &mesh->fHead); return e; } 

पीवीएस-स्टूडियो चेतावनी:

• V773 'newVertex1' पॉइंटर को जारी किए बिना फ़ंक्शन को बाहर किया गया था। एक स्मृति रिसाव संभव है। mesh.c 312
• V773 'newVertex2' पॉइंटर जारी किए बिना फ़ंक्शन को बाहर किया गया था। एक स्मृति रिसाव संभव है। mesh.c 312
• V773 'newFace' पॉइंटर जारी किए बिना फ़ंक्शन को बाहर किया गया था। एक स्मृति रिसाव संभव है। mesh.c 312

फ़ंक्शन कई संरचनाओं के लिए मेमोरी आवंटित करता है और इसे पॉइंटर्स newVertex1 , newVertex2 (दिलचस्प नाम, सही?) और newFace को पास करता है । यदि उनमें से एक शून्य हो जाता है, तो फ़ंक्शन के अंदर आरक्षित सभी मेमोरी को मुक्त कर दिया जाता है, जिसके बाद नियंत्रण प्रवाह फ़ंक्शन को छोड़ देता है।

यदि सभी तीन संरचनाओं के लिए मेमोरी सही ढंग से आबंटित होती है, और MakeEdge (& mesh-> eHead) फ़ंक्शन NULL देता है ? नियंत्रण प्रवाह दूसरे रिटर्न तक पहुंच जाएगा।

चूंकि संकेत newVertex1 , newVertex2 और newFace स्थानीय चर हैं, वे फ़ंक्शन से बाहर निकलने के बाद मौजूद रहना बंद कर देंगे। लेकिन जो स्मृति उनसे संबंधित थी उसकी रिहाई नहीं होगी। यह आरक्षित रहेगा, लेकिन अब हमारे पास इसकी पहुंच नहीं होगी।

ऐसी स्थितियों को मेमोरी लीक कहा जाता है। ऐसी त्रुटि के साथ एक विशिष्ट परिदृश्य: कार्यक्रम के लंबे समय तक उपयोग के साथ, यह अधिक से अधिक रैम का उपभोग करना शुरू कर देता है, इसकी थकावट तक।

यह ध्यान दिया जाना चाहिए कि इस उदाहरण में, तीसरा रिटर्न गलत नहीं है। MakeVertex और MakeFace फ़ंक्शंस आवंटित डेटा के पते को अन्य डेटा संरचनाओं में स्थानांतरित करते हैं, जिससे इसकी रिलीज़ के लिए जिम्मेदारी सौंप दी जाती है।

अगला दोष विधि में है, जिसमें 90 लाइनें लगती हैं। सुविधा के लिए, मैंने इसे कम कर दिया, केवल समस्या क्षेत्रों को छोड़कर।

 void AstroCalcDialog::drawAngularDistanceGraph() { .... QVector<double> xs, ys; .... } 

सिर्फ एक लाइन बची। मैं आपको एक संकेत देता हूं: यह केवल xs और ys ऑब्जेक्ट्स का उल्लेख है।

पीवीएस-स्टूडियो चेतावनी:

• V808 'xs' ऑब्जेक्ट 'QVector' प्रकार का बनाया गया था, लेकिन इसका उपयोग नहीं किया गया था। एस्ट्रोकाॅलडियोगॉग। 5329
• V808 'ys' ऑब्जेक्ट 'QVector' प्रकार का बनाया गया था, लेकिन इसका उपयोग नहीं किया गया था। एस्ट्रोकाॅलडियोगॉग। 5329

वैक्टर xs और ys बनाए जाते हैं, लेकिन कहीं भी उपयोग नहीं किए जाते हैं। यह पता चलता है कि हर बार जब आप ड्राअंगुलरडिस्टेंसग्राफ विधि का उपयोग करते हैं, तो एक खाली कंटेनर का एक अतिरिक्त निर्माण और विलोपन होता है। मुझे लगता है कि यह विज्ञापन रीफैक्टरिंग के बाद कोड में बना रहा। यह, ज़ाहिर है, एक गलती नहीं है, लेकिन आपको अतिरिक्त कोड को हटा देना चाहिए।

अजीब प्रकार की जातियाँ

इस तरह के स्वरूपण के बाद एक और उदाहरण इस प्रकार है:

 void SatellitesDialog::updateSatelliteData() { .... // set default buttonColor = QColor(0.4, 0.4, 0.4); .... } 

यह समझने के लिए कि त्रुटि क्या है, आपको Qcolor वर्ग के निर्माणकर्ताओं के प्रोटोटाइप को देखना होगा:

पीवीएस-स्टूडियो चेतावनी:

• V674 'डबल' प्रकार के शाब्दिक '0.4' को 'क्यूकलर' फ़ंक्शन कहते हुए 'इंट' प्रकार के लिए निहित किया जा रहा है। पहले तर्क का निरीक्षण करें। SatellitesDialog.cpp 413
• V674 'डबल' प्रकार के शाब्दिक '0.4' को 'क्यूकलर' फ़ंक्शन कहते हुए 'इंट' प्रकार के लिए निहित किया जा रहा है। दूसरे तर्क का निरीक्षण करें। SatellitesDialog.cpp 413
• V674 'डबल' प्रकार के शाब्दिक '0.4' को 'क्यूकलर' फ़ंक्शन कहते हुए 'इंट' प्रकार के लिए निहित किया जा रहा है। तीसरे तर्क का निरीक्षण करें। SatellitesDialog.cpp 413

Qcolor वर्ग के पास ऐसे निर्माता नहीं हैं जो दोहरे प्रकार को स्वीकार करते हैं, इसलिए उदाहरण में तर्क को संक्षेप में int में बदल दिया जाएगा। यह बटन r मान के फ़ील्ड r , g , b का कारण बनता है जिसका मान 0 होता है ।

यदि प्रोग्रामर का उद्देश्य डबल टाइप के मूल्यों से ऑब्जेक्ट बनाना है, तो उसे एक अलग कंस्ट्रक्टर का उपयोग करना चाहिए।

उदाहरण के लिए, आप एक कंस्ट्रक्टर का उपयोग कर सकते हैं जो लिखकर Qrgb स्वीकार करता है:

 buttonColor = QColor(QColor::fromRgbF(0.4, 0.4, 0.4)); 

यह अलग तरह से किया जा सकता था। Qt आरजीबी रंगों को इंगित करने के लिए रेंज [0, 255] में पूर्ण मानों या पूर्णांक मानों का उपयोग करता है।

इसलिए, प्रोग्रामर वास्तविक से पूर्णांक तक मानों को इस तरह लिखकर अनुवाद कर सकता है:

 buttonColor = QColor((int)(255 * 0.4), (int)(255 * 0.4), (int)(255 * 0.4)); 

या बस

 buttonColor = QColor(102, 102, 102); 

क्या आप ऊब गए हैं? चिंता न करें: हमारे आगे और भी दिलचस्प गलतियाँ हैं।

"अंतरिक्ष में गेंडा।" तारामंडल से देखें।

अन्य त्रुटियां

अंत में, मैंने आपको कुछ और स्वादिष्ट छोड़ दिया :) चलो उनमें से एक के लिए नीचे उतरो।

 HipsTile* HipsSurvey::getTile(int order, int pix) { .... if (order == orderMin && !allsky.isNull()) { int nbw = sqrt(12 * 1 << (2 * order)); int x = (pix % nbw) * allsky.width() / nbw; int y = (pix / nbw) * allsky.width() / nbw; int s = allsky.width() / nbw; QImage image = allsky.copy(x, y, s, s); .... } .... } 

PVS-Studio चेतावनी: V634 '*' ऑपरेशन की प्राथमिकता '<<' ऑपरेशन की तुलना में अधिक है। यह संभव है कि कोष्ठक का प्रयोग अभिव्यक्ति में किया जाए। StelHips.cpp 271

खैर, क्या आप गलती ढूंढ सकते हैं? अधिक विस्तार से अभिव्यक्ति (12 * 1 << (2 * क्रम)) पर विचार करें। विश्लेषक याद करता है कि ऑपरेशन ' * ' में बिट शिफ्ट ऑपरेशन ' << ' की तुलना में अधिक प्राथमिकता है। यह देखना आसान है कि 12 को 1 से गुणा करना व्यर्थ है, और 2 * ऑर्डर के आसपास कोष्ठक की आवश्यकता नहीं है।

  ,    : int nbw = sqrt(12 * (1 << 2 * order));     <i>12 </i>     . 

नोट। इसके अतिरिक्त, मैं यह नोट करना चाहता हूं कि यदि सही ऑपरेंड ' << ' का मान लेफ्ट ऑपरेंड के बिट्स की संख्या से अधिक या बराबर है, तो परिणाम परिभाषित नहीं है। चूंकि संख्यात्मक शाब्दिक रूप से डिफ़ॉल्ट रूप से अंतर है, जो 32 बिट्स लेता है, ऑर्डर पैरामीटर का मान 15 से अधिक नहीं होना चाहिए। अन्यथा, अभिव्यक्ति के मूल्यांकन में अपरिभाषित व्यवहार हो सकता है।

हम जारी रखते हैं। नीचे दी गई विधि बहुत भ्रामक है, लेकिन मुझे यकीन है कि एक परिष्कृत पाठक त्रुटि का पता लगाने में सक्षम होगा :)

 /* inherits documentation from base class */ QCPRange QCPStatisticalBox:: getKeyRange(bool& foundRange, SignDomain inSignDomain) const { foundRange = true; if (inSignDomain == sdBoth) { return QCPRange(mKey - mWidth * 0.5, mKey + mWidth * 0.5); } else if (inSignDomain == sdNegative) { if (mKey + mWidth * 0.5 < 0) return QCPRange(mKey - mWidth * 0.5, mKey + mWidth * 0.5); else if (mKey < 0) return QCPRange(mKey - mWidth * 0.5, mKey); else { foundRange = false; return QCPRange(); } } else if (inSignDomain == sdPositive) { if (mKey - mWidth * 0.5 > 0) return QCPRange(mKey - mWidth * 0.5, mKey + mWidth * 0.5); else if (mKey > 0) return QCPRange(mKey, mKey + mWidth * 0.5); else { foundRange = false; return QCPRange(); } } foundRange = false; return QCPRange(); } 

पीवीएस-स्टूडियो चेतावनी: V779 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। qcustomplot.cpp 19512।

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

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

इस कोड के टुकड़े को फिर से तैयार किया जाना चाहिए, जो आउटपुट में अधिक साफ काम कर रहा है। उदाहरण के लिए, इस तरह:

 /* inherits documentation from base class */ QCPRange QCPStatisticalBox:: getKeyRange(bool& foundRange, SignDomain inSignDomain) const { foundRange = true; switch (inSignDomain) { case sdBoth: { return QCPRange(mKey - mWidth * 0.5, mKey + mWidth * 0.5); break; } case sdNegative: { if (mKey + mWidth * 0.5 < 0) return QCPRange(mKey - mWidth * 0.5, mKey + mWidth * 0.5); else if (mKey < 0) return QCPRange(mKey - mWidth * 0.5, mKey); break; } case sdPositive: { if (mKey - mWidth * 0.5 > 0) return QCPRange(mKey - mWidth * 0.5, mKey + mWidth * 0.5); else if (mKey > 0) return QCPRange(mKey, mKey + mWidth * 0.5); break; } } foundRange = false; return QCPRange(); } 

हमारी समीक्षा में अंतिम त्रुटि होगी जो मुझे सबसे ज्यादा पसंद आई। मुसीबत का स्थान कोड छोटा और सरल है:

 Plane::Plane(Vec3f &v1, Vec3f &v2, Vec3f &v3) : distance(0.0f), sDistance(0.0f) { Plane(v1, v2, v3, SPolygon::CCW); } 

क्या आपने कुछ संदिग्ध देखा है? हर कोई नहीं कर सकता :)

PVS-Studio चेतावनी: V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> प्लेन :: प्लेन (....)' का उपयोग किया जाना चाहिए। विमान। 29 29

प्रोग्रामर को उम्मीद थी कि ऑब्जेक्ट के कुछ क्षेत्रों को नेस्टेड कंस्ट्रक्टर के अंदर आरंभीकृत किया जाएगा, लेकिन यह इस तरह से निकला: जब प्लेन कंस्ट्रक्टर (Vec3f & v1, Vec3f & v2, Vec3f और v3) कहा जाता है, तो इसके अंदर एक अनाम अस्थायी ऑब्जेक्ट बनाया जाता है, जिसे तुरंत हटा दिया जाता है। परिणामस्वरूप, वस्तु का एक हिस्सा असिंचित रहता है।

कोड को सही ढंग से काम करने के लिए, आपको सी ++ 11 की सुविधाजनक और सुरक्षित सुविधा का उपयोग करना चाहिए - प्रतिनिधि निर्माणकर्ता:

 Plane::Plane(Vec3f& v1, Vec3f& v2, Vec3f& v3) : Plane(v1, v2, v3, SPolygon::CCW) { distance = 0.0f; sDistance = 0.0f; } 

लेकिन अगर आप भाषा के पुराने संस्करणों के लिए संकलक का उपयोग करते हैं, तो आप इस तरह लिख सकते हैं:

 Plane::Plane(Vec3f &v1, Vec3f &v2, Vec3f &v3) : distance(0.0f), sDistance(0.0f) { this->Plane::Plane(v1, v2, v3, SPolygon::CCW); } 

या तो:

 Plane::Plane(Vec3f &v1, Vec3f &v2, Vec3f &v3) : distance(0.0f), sDistance(0.0f) { new (this) Plane(v1, v2, v3, SPolygon::CCW); } 

मैं ध्यान देता हूं कि पिछले दो तरीके बहुत खतरनाक हैं । इसलिए, आपको बहुत सावधान रहना चाहिए और अच्छी तरह से समझना चाहिए कि ऐसे तरीके कैसे काम करते हैं।

निष्कर्ष

स्टेलारियम कोड की गुणवत्ता के बारे में क्या निष्कर्ष निकाला जा सकता है? ईमानदारी से, बहुत गलतियाँ नहीं थीं। साथ ही, पूरे प्रोजेक्ट में, मुझे एक भी त्रुटि नहीं मिली जिसमें कोड अपरिभाषित व्यवहार से बंधा हो। ओपनसोर्स प्रोजेक्ट के लिए, कोड की गुणवत्ता उच्च स्तर पर निकली, जिसके लिए मैं डेवलपर्स से अपनी टोपी लेता हूं। तुम लोग महान हो! मुझे आपकी परियोजना की समीक्षा करने में प्रसन्नता हुई।

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

मुझे विशेष रूप से "नक्षत्र कला" मोड पसंद है। एक अजीब नृत्य में पूरे आकाश को कवर करने वाले विशाल आकृतियों की दृष्टि लुभावनी है।

"एक अजीब नृत्य।" तारामंडल से देखें।

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

मुझे आशा है कि आप मेरे लेख को पढ़ने में रुचि रखते थे, और आपने अपने लिए कुछ नया और उपयोगी सीखा। और मैं चाहता हूं कि डेवलपर्स को मिली त्रुटियों का शीघ्र सुधार हो।

हमारे चैनलों की सदस्यता लें और प्रोग्रामिंग की दुनिया से खबरों के लिए बने रहें!

• Vk: @pvsstudio_rus
• टेलीग्राम: @pvsstudio_rus
• इंस्टाग्राम: @pvsstudio_rus
• ट्विटर: @pvsstudio_rus
• YouTube: @PVSStudioTool

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