कंपाइलर चेतावनियों को अक्षम क्यों करना चाहिए?

Question

यह उत्तर और इसमें जोड़ी गई टिप्पणियां #pragmaनिर्देशों का उपयोग करके कई संकलक चेतावनियों को अक्षम करने का एक तरीका दिखाती हैं ।

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

Comments

यकीन नहीं होता कि किसी ने इसे बंद के लिए चिह्नित किया। मेरे लिए एक उचित उचित प्रश्न की तरह लगता है। +1

@ ऑल्टेयर पिट्स: मैंने प्रोग्रामर्स के लिए एक माइग्रेशन प्रस्तावित किया। मुझे अपनी गलती का एहसास बाद में हुआ।

— तुगरुल एट्स

चेतावनी संदेश एक कारण के लिए हैं, हां, लेकिन एक कारण यह भी है कि वे त्रुटि संदेश क्यों नहीं हैं ।

— सोलोमन स्लो

@jameslarge आपकी टिप्पणी से स्थिति अच्छी हो जाती है। चेतावनी एक संकलक है जो आपको बता रहा है कि एक स्थिति बहुत ही गलत है , जिसका अर्थ संभवतः सही है । अगर यह निश्चित रूप से गलत था तो यह एक त्रुटि होगी। चूँकि कुछ चेतावनियाँ झूठी सकारात्मक हो सकती हैं, इसलिए हमेशा कोड लिखने का एक तरीका होना चाहिए ताकि यह चेतावनी समाप्त हो जाए। दुर्भाग्य से, कभी-कभी ऐसा करने का सबसे व्यावहारिक तरीका एक प्रज्ञा के माध्यम से होता है; इसलिए यह नाम।

— एरिक लिपर्ट

यह अक्षम नहीं है, यह छिपा है। यह समस्या अभी भी वहाँ है कि आप इसे नहीं देखेंगे

— सिसिर

Answer 1

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

मुझे एपीआई के सभी उपयोगकर्ताओं को यह बताने का सबसे अच्छा तरीका है कि वे इस पद्धति को कॉल न करें, इसे अप्रचलित चिह्नित करना था। हालांकि, इसका मतलब था कि एक वैध उपयोग मामला एक संकलन चेतावनी के रूप में चिह्नित किया गया था।

एरिक लिपर्ट ने चेतावनियों के बारे में कुछ पोस्ट लिखी हैं, जहां आपको जानकारी मिल जाएगी कि कंपाइलर टीम चेतावनी के बारे में कैसे सोचती है।

आंतरिक प्रकार के आंतरिक क्षेत्र

निर्देशों का उपयोग करते हुए अप्रयुक्त चेतावनी के साथ चिह्नित नहीं हैं

Answer 2

यहाँ कुछ चेतावनियाँ दी गई हैं जहाँ दस्तावेज़ीकरण कारण बताता है कि आप उन्हें निष्क्रिय क्यों करना चाहते हैं:

• http://msdn.microsoft.com/en-US/library/4bw5ewxy(v=VS.80).aspx
• http://msdn.microsoft.com/en-US/library/sa4zat99(v=VS.80).aspx
• http://msdn.microsoft.com/en-US/library/9x19t380(v=VS.80).aspx

अन्य उदाहरणों में मूल्यह्रास विधियों का उपयोग करने के बारे में चेतावनी शामिल है यदि आप जानते हैं कि आप अभी भी पुरानी पद्धति का उपयोग करना चाहते हैं या ऐसे निजी सदस्य हैं जो कभी भी स्थानीय रूप से नहीं पढ़े जाते हैं, लेकिन इसके बजाय प्रतिबिंब के साथ।

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

Comments

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

— ग्रेग जैक्सन

मैंने एक्सेल में बहुत सारी मैक्रो प्रोग्रामिंग की है और मुझे विभिन्न कारणों जैसे ऑटो सेव, ऑटो एग्जिट, नोटिफिकेशन आदि के लिए चेतावनियों को निष्क्रिय करना पड़ा, बेशक आप इन चेतावनियों के बारे में नहीं हो सकते ...

— डेव मेस

@ICR मुझे जावा में कंपाइलर चेतावनियों को अक्षम करना याद नहीं है। मेरे द्वारा किए जाने वाले सभी पदावनत विधियों का उपयोग करने से बचें।

— महमूद होसम

@ ममौद मैं अक्सर अपने आप को "अनियंत्रित" चेतावनियों के बारे में बताता हूं जब कुछ भी जेनेरिक के साथ दूरस्थ रूप से जटिल होता है। लेकिन यह हास्यास्पद चेतावनी के मोर्चे पर C ++ के साथ जावा को गांठ लगाने के लिए शायद अनुचित है - मेरे जवाब को संपादित किया।

— ICR

@ICR जावा संग्रह में टाइप सुरक्षा प्रदान करने के लिए जेनरिक के उपयोग को लागू करता है, जबकि कुछ इसे एक बाधा के रूप में देखते हैं, मुझे लगता है कि यह एक विशेषता के रूप में है, यह लेखन कोड को थोड़ा दर्दनाक बनाता है, लेकिन यह जीवन बचाता है, और हाँ, सी + + बायलर आउटपुट जब यह STL या टेम्प्लेट के साथ कुछ भी होता है तो कुछ डरावना होता है।

— महमूद होसम

Answer 3

सी में एक उदाहरण है कि मैं नियमित रूप से वेरिएंट का सामना करता हूं:

int doSomething(int argument1)
{
#ifdef HARDWARE_TYPE_A
    performAction(argument1);
#else
    displayNotSupportedMessage();
#endif
}

यह तर्क केवल कुछ प्लेटफार्मों पर प्रासंगिक है, लेकिन उन पर जहां यह प्रासंगिक नहीं है मेरे कंपाइलर शिकायत करेंगे, और चूंकि मैंने चेतावनी को त्रुटियों में परिवर्तित कर दिया है, इसलिए यह इसे रोक देगा।

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

Answer 4

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

Answer 5

मैं एम्बेडेड काम करता हूं और मुझे एक या दो बार याद करने लगता है जब मैंने चेतावनी को निष्क्रिय कर दिया है क्योंकि मैं कुछ ऐसा कर रहा था जो संकलक के लिए बेकार लग रहा था, लेकिन जो वास्तव में हार्डवेयर में वास्तविक दुनिया प्रभाव था।

केवल दूसरा समय है जब मैं कुछ डेटा संरचना के असमान विचारों के साथ कोडबेस पर काम कर रहा हूं (जैसे बाइट्स की सरणियों का प्रतिनिधित्व कैसे करें - चार या अहस्ताक्षरित चार?)। इन मामलों में, मैं चेतावनियों को अक्षम कर सकता हूं क्योंकि विकल्प कोड के माध्यम से जाने वाले दिन बिताना है और या तो एक हिस्से को संशोधित करना है, या सैकड़ों जातियों में डालना है।

Answer 6

चुनिंदा कंपाइलर चेतावनियों को अक्षम करने के लिए कुछ कारण हैं, यहां तक ​​कि उन परियोजनाओं के लिए भी जो सर्वोत्तम प्रथाओं के लिए प्रयास करते हैं।

• अलग-अलग कंपाइलर (या एक ही कंपाइलर के अलग-अलग संस्करण) :
  कंपाइलर अलग-अलग तरीकों से चेतावनी को संभालते हैं। गलत-सकारात्मक चेतावनी देना जो अन्य संकलक को प्रभावित नहीं करते हैं। इस मामले में यह उन संकलकों के लिए चेतावनी को निष्क्रिय करने के लिए समझ में आता है, एक झूठी-सकारात्मक चेतावनी को शांत करने के लिए मान्य कोड को संपादित करने के बजाय, जो केवल कुछ संकलक को प्रभावित करता है, विशेष रूप से पुराने संकलक के लिए जो अंततः वैसे भी असमर्थित हो जाएगा।
• उत्पन्न कोड के साथ:
  कोड हाइजीन से संबंधित कुछ चेतावनियाँ (डेड कोड, सशर्त बयानों की डुप्लिकेट बॉडी, तुलनाएं जो कि हद से ज्यादा होती हैं) को सुरक्षित रूप से नजरअंदाज किया जा सकता है क्योंकि वे हानिरहित हैं और कंपाइलर उन्हें बाहर निकाल देगा।
  कोड बनाना जो इन हानिरहित चेतावनियों को नहीं बढ़ाता है, निश्चित रूप से एक विकल्प भी है, लेकिन फिर अधिक परेशानी हो सकती है।
• बाहरी कोड के लिए चेतावनी:
  शायद आप एक अच्छी तरह से ज्ञात qsort या md5 चेकसम कार्यान्वयन का उपयोग करते हैं जो आपकी परियोजना में शामिल है। कोड का उपयोग कई परियोजनाओं द्वारा किया जाता है और अच्छी तरह से काम करने के लिए जाना जाता है, फिर भी कुछ पिकी चेतावनी हो सकती हैं जो आपके अपने कोड के लिए सामान्य रूप से सही होती हैं।
  बाहरी कोड के लिए, हालांकि यह सिर्फ चेतावनी को अक्षम करने के लिए कम परेशानी हो सकती है (यह निश्चित रूप से हानिरहित है)।
• सिस्टम हेडर के कारण होने वाली चेतावनियाँ:
  उदाहरण के लिए जीसीसी / क्लैग के बावजूद -isystem, ऐसे मामले हैं जब सिस्टम हेडर में अंतर चेतावनी का कारण बनता है जिसे नजरअंदाज किया जा सकता है (शायद एक फ़ंक्शन का एक सिस्टम पर हस्ताक्षरित वापसी मूल्य है, लेकिन दूसरे पर नहीं), -Wsign-compareचेतावनी को ट्रिगर करता है ।
  एक अन्य मामला सिस्टम हेडर में मैक्रोज़ को परिभाषित किया जा सकता है, आप उन्हें संशोधित करने के लिए मैक्रोज़ को अपने स्वयं के कोड में कॉपी-पेस्ट कर सकते हैं, लेकिन सभी चीजों ने 3 पार्टी पुस्तकालयों से मैक्रोज़ को बनाए रखने के बारे में चिंता नहीं करना बेहतर माना ... इसलिए यह बेहतर है चेतावनी को शांत करने के लिए (शायद मैक्रो किसी कलाकार को मिस करता है -Wsign-conversionजैसे)।
• स्टब कोड में अप्रयुक्त चेतावनी:
  आप अप्रयुक्त मापदंडों की चेतावनी दे सकते हैं, हालांकि जब पूरी लाइब्रेरी को एक ही फाइल में स्टबिंग किया जाता है जिसमें केवल स्टब फ़ंक्शंस होते हैं - तो यह (void)arg1; (void)arg2; (void)arg3; ...हर स्टब फ़ंक्शन के शरीर में बल देने में सहायक नहीं होता है।
  बेहतर है बस -Wunused-parameterइस मामले में दबा दें ।

ध्यान दें कि इन सभी उदाहरणों में, अपने मान लिया चेतावनी को अक्षम करने नहीं वास्तविक कीड़े को छिपाने के लिए जा रहा है, जैसे: -Wredundant-decls, -Wunused-parameter, -Wdouble-promotion, शायद -Wpedantic... और आप जानते हैं कि आप क्या कर रहे हैं!

Answer 7

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

इसके अलावा मैं किसी के बारे में सोच भी नहीं सकता। अक्षम चेतावनी आमतौर पर एक "बदसूरत हेक्स" का संकेत है ...

Answer 8

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

इस बीच, हमें इसे संकलित करने की आवश्यकता थी, और हम चाहते थे कि "चेतावनी त्रुटियां हैं" विकल्प चालू हो, इसलिए हमने कुछ चेतावनियों को दबा दिया।

Answer 9

वर्तमान में, केवल चेतावनी जिसे मैं कभी भी अनदेखा करता हूं

  warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)  

क्योंकि Microsoft C ++ विनिर्देशन को लागू नहीं करता है (प्रलेखन भी कहता है कि वे ऐसा नहीं करते हैं!) और फ़ंक्शंस को विशिष्ट थ्रो घोषित करने की अनुमति देते हैं और सभी फ़ंक्शंस केवल फेंक () या थ्रो (...), यानी कुछ भी नहीं या सब कुछ फेंक सकते हैं।

हेल्प व्यूअर 1.1 से:

 A function is declared using exception specification, which Visual C++ accepts but does not implement. Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications.