मैं अप्रयुक्त चर के बारे में एक चेतावनी को कैसे चुप करूं?

Question

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

चेतावनी के आसपास कोडिंग का सबसे अच्छा तरीका क्या होगा?

समारोह के आसपास एक #ifdef?

#ifdef _MSC_VER
void ProcessOps::sendToExternalApp(QString sAppName, QString sImagePath, qreal qrLeft, qreal qrTop, qreal qrWidth, qreal qrHeight)
#else
void ProcessOps::sendToExternalApp(QString sAppName, QString sImagePath, qreal /*qrLeft*/, qreal /*qrTop*/, qreal /*qrWidth*/, qreal /*qrHeight*/)
#endif
{

यह बहुत बदसूरत है लेकिन लगता है कि जिस तरह से संकलक पसंद करेंगे।

या क्या मैं फ़ंक्शन के अंत में चर को शून्य असाइन करता हूं? (जो मुझे नफरत है क्योंकि यह एक संकलक चेतावनी को चुप करने के लिए कार्यक्रम के प्रवाह में कुछ बदल रहा है)।

क्या कोई सही तरीका है?

Comments

मुझे सिर्फ एहसास हुआ कि आपने पिछले नवंबर में इसी तरह का सवाल पूछा था। यही कारण है कि यह परिचित लग रहा है! ;) stackoverflow.com/questions/308277/…

— एलेक्स बी

क्यों न केवल उन्हें दोनों संकलक के लिए टिप्पणी करें? यदि arg एक पर अप्रयुक्त है, तो संभवतः इसे दूसरे पर अप्रयुक्त किया जाएगा ...

— Roger Lipscombe

आपको पता होना चाहिए कि Qt के पास इसके लिए एक Q_UNUSEDमैक्रो है। दस्तावेज में इसे देखें।

— इवान टेरान

C समाधान C ++ में भी ठीक काम करता है: stackoverflow.com/a/3599170/1904815

— JonnyJD

-अगर अप्रयुक्त-पैरामीटर भी एक विकल्प हो सकता है यदि आपके पास संकलक-विशिष्ट बिल्ड फ़्लैग हो सकते हैं

— कोड Abominator

Answer 1

आप इसे " (void)var;" अभिव्यक्ति (कुछ भी नहीं करता है) में रख सकते हैं ताकि एक कंपाइलर देखता है कि इसका उपयोग किया जाता है। यह संकलक के बीच पोर्टेबल है।

उदाहरण के लिए

void foo(int param1, int param2)
{
    (void)param2;
    bar(param1);
}

या,

#define UNUSED(expr) do { (void)(expr); } while (0)
...

void foo(int param1, int param2)
{
    UNUSED(param2);
    bar(param1);
}

Comments

+1 - फिर भी मैं प्रलेखित करूंगा कि आप चर का उपयोग क्यों नहीं करते, भले ही वह वहां क्यों न हो।

— टोबियास लैंगनर सिप

यह Q_UNUSEDसिद्धांत में कैसे लागू किया जाता है।

— दिमित्री वोलोसनीख

@Cameron आप C ++ में बस पैरामीटर नाम छोड़ सकते हैं। यदि यह टेम्प्लेटेड है, तो इसका उपयोग C में नहीं किया जाएगा, इसलिए आपको कास्ट-टू-वॉयड ट्रिक की आवश्यकता नहीं है।

— एलेक्स बी

बस #define UNUSED(expr) (void)(expr)काम भी करना चाहिए (बिना देर किए)।

— जॉनीजेड

मुझे आश्चर्य है कि एक वैचारिक टेम्पलेट के लिए यह कैसे करना है। में template<typename... Args> void f(const Args&... args)मैं लिख नहीं सकता (void)args;या (void)args...;क्योंकि दोनों वाक्यविन्यास त्रुटियाँ हैं।

— पणजी

Answer 2

जीसीसी और क्लैंग में आप __attribute__((unused))अपने लक्ष्य को प्राप्त करने के लिए प्रीप्रोसेसर निर्देश का उपयोग कर सकते हैं ।
उदाहरण के लिए:

int foo (__attribute__((unused)) int bar) {
   return 0;
}

Comments

कॉलबैक फ़ंक्शन के लिए यह सबसे अच्छा समाधान है।

— सोनिक एटम

क्लैंग

— अलेक्जेंडर

Answer 3

C ++ 17 अब [[maybe_unused]]विशेषता प्रदान करता है ।

http://en.cppreference.com/w/cpp/language/attributes

काफी अच्छा और मानक।

Answer 4

यदि आप इसका उपयोग नहीं करते हैं, तो आपका वर्तमान समाधान सर्वोत्तम है - पैरामीटर नाम पर टिप्पणी करें। यह सभी कंपाइलरों पर लागू होता है, इसलिए आपको GCC के लिए विशेष रूप से करने के लिए प्री-प्रोसेसर का उपयोग करने की आवश्यकता नहीं है।

Comments

बस इस उत्तर को सुदृढ़ करने के लिए - आपको #ifdef की आवश्यकता नहीं है, बस अप्रयुक्त पैरामीटर नामों की टिप्पणी करें।

— क्वामराना

मेरे पास एक मामला है जहां पैरामीटर एक कॉलबैक का हिस्सा है और टिप्पणी करने से यह संकलन टूट जाता है (इसलिए मुझे यकीन नहीं है कि g++इसके बारे में चेतावनी क्यों दी गई है।) ऐसे मामले में, आप क्या सलाह देंगे?

— ड्रू नोक

अप्रयुक्त मापदंडों के साथ एक इनलाइन वर्चुअल विधि की कल्पना करें / * टिप्पणी * /, इंटरफ़ेस का क्लाइंट अधिकांश आईडीई में स्वतः पूर्णता के दौरान पैरामीटर नाम नहीं देखेगा। इस मामले में UNUSED () समाधान अधिक सुविधाजनक है, हालांकि कम क्लीनर।

— cbuchart

मुझे लगता है कि सरल बेहतर है, टिप्पणी करना बहुत स्पष्ट है

— फाइववेल 16'18

Answer 5

C ++ 17 अद्यतन

C ++ 17 में हम उस विशेषता को प्राप्त करते हैं [[हो सकता है_अनुसूचित] जो कि [dcl.attr.unused] में शामिल है

विशेषता-टोकन शायद_अनुसूचित इंगित करता है कि एक नाम या इकाई संभवतः जानबूझकर अप्रयुक्त है। यह प्रत्येक विशेषता-सूची में एक बार दिखाई देगा और कोई विशेषता-तर्क-खंड मौजूद नहीं होगा। ...

उदाहरण:

 [[maybe_unused]] void f([[maybe_unused]] bool thing1,
                        [[maybe_unused]] bool thing2) {
  [[maybe_unused]] bool b = thing1 && thing2;
    assert(b);
 }

कार्यान्वयन को चेतावनी नहीं दी जानी चाहिए कि बी अप्रयुक्त है, चाहे NDEBUG परिभाषित हो या न हो। उदाहरण का]

निम्नलिखित उदाहरण के लिए:

int foo ( int bar) {
    bool unused_bool ;
    return 0;
}

क्लैंग और जीसीसी दोनों एक डायग्नोस्टिक का उपयोग कर उत्पन्न करते हैं -वेल-टेक्स्ट दोनों बार और अप्रयुक्त_बुल ( यह लाइव देखें ) के लिए।

जोड़ते समय [[शायद_उन] ने निदान को मौन कर दिया:

int foo ([[maybe_unused]] int bar) {
    [[maybe_unused]] bool unused_bool ;
    return 0;
}

यह सीधा प्रसारण दिखाई ।

C ++ 17 से पहले

C ++ 11 में UNUSEDमैक्रो का एक वैकल्पिक रूप लैंबडा एक्सप्रेशन ( बेन डीन के माध्यम से ) का उपयोग अप्रयुक्त चर के कैप्चर के साथ बनाया जा सकता है :

#define UNUSED(x) [&x]{}()

लैम्ब्डा अभिव्यक्ति के तत्काल मंगलाचरण को अनुकूलित किया जाना चाहिए, निम्नलिखित उदाहरण दिए गए हैं:

int foo (int bar) {
    UNUSED(bar) ;
    return 0;
}

हम Godbolt में देख सकते हैं कि कॉल को अनुकूलित किया गया है:

foo(int):
xorl    %eax, %eax
ret

Comments

तो आप C ++ 11 का उल्लेख करते हैं और फिर एक मैक्रो प्रस्तुत करने का प्रबंधन करते हैं ?! आउच! शायद एक फ़ंक्शन का उपयोग करना क्लीनर होगा? template <class T> inline void NOTUSED( T const & result ) { static_cast<void>(result); }तुम भी समारोह में एक मेमने का उपयोग कर सकते हैं, मुझे लगता है।

— एलेक्सिस विल्के

Godbolt एक महान संसाधन है

— 19

[&x]{}()वास्तव में चेतावनी को चुप नहीं करता है, लेकिन चेतावनी को कॉल करने वाले फ़ंक्शन से लैंबडा के बजाय पास करता है। जब तक कंपाइलर इसे एक चेतावनी के रूप में पहचानते हैं, तब तक समय लगेगा, लेकिन क्लैंग-टिड्डी पहले से ही कैप्चर सूची में अप्रयुक्त चर के बारे में शिकायत करता है।

— nVxx

Answer 6

एक साफ-सुथरा तरीका यह है कि आप केवल चर नामों पर टिप्पणी करें:

int main(int /* argc */, char const** /* argv */) {
  return 0;
}

Comments

यह अच्छा नहीं है अगर आपके पास डॉक्सीजन है और मापदंडों का दस्तावेज बनाना चाहते हैं।

— एलेक्सिस विल्के

@ एलेक्सिसविल्के: कि डॉक्स में एक बग के रूप में अर्हता प्राप्त होगी, IMO

— 6502

आप #ifdef DOXYGEN पर सशर्त रूप से #_PROJECT_UNUSED (argname) लगा सकते हैं, ताकि doxygen नाम और वास्तविक कंपाइलर को int main (int YourPROPROECTECT_UNUSED (argc), ...) के माध्यम से देख सके। शानदार नहीं है, लेकिन काम करता है।

— शुभम

मुझे इस तरह की कई नेस्टेड टिप्पणियों के साथ कोड के एक ब्लॉक पर टिप्पणी करना बहुत दर्दनाक लगता है। (कंपाइलर हर एक के बारे में शिकायत करता है)।

— जेफ मैक्लिंटॉक

@JeffMcClintock सिर्फ सिंगल-लाइन टिप्पणियों का उपयोग करें। अधिकांश सभ्य संपादक ऊर्ध्वाधर ब्लॉक संपादन (जैसे [Ctrl] + [V] विम में) का समर्थन करते हैं। अन्यथा, #if 0 / #endifब्लॉक टिप्पणियों का उपयोग करें ।

— रुस्लान

Answer 7

एक सहकर्मी सिर्फ इस अच्छी छोटी मैक्रो के लिए मुझे बताया यहाँ

आसानी के लिए मैं नीचे दिए गए मैक्रो को शामिल करूंगा।

#ifdef UNUSED
#elif defined(__GNUC__) 
# define UNUSED(x) UNUSED_ ## x __attribute__((unused)) 
#elif defined(__LCLINT__) 
# define UNUSED(x) /*@unused@*/ x 
#else 
# define UNUSED(x) x 
#endif

void dcc_mon_siginfo_handler(int UNUSED(whatsig))

Comments

"अच्छा" "मैक्रो" "सी ++" - पिक 2.

— जेफ मैकक्लिंटॉक

Answer 8

जीसीसीडिफ़ॉल्ट रूप से इन चेतावनियों को चिह्नित नहीं करता है। इस चेतावनी को -Wunused-parameterसंकलक के पास या स्पष्ट रूप से पासिंग -Wall -Wextra(या संभवत: झंडे के कुछ अन्य संयोजन) द्वारा पारित करने पर स्पष्ट रूप से चालू किया जाना चाहिए ।

अप्रयुक्त पैरामीटर चेतावनियों को बस -Wno-unused-parameterसंकलक को पास करके दबाया जा सकता है , लेकिन ध्यान दें कि यह अक्षम करने वाला ध्वज संकलक कमांड लाइन में इस चेतावनी के लिए किसी भी सक्षम सक्षम झंडे के बाद आना चाहिए, ताकि यह प्रभावी हो सके।

Comments

हालांकि, यह सवाल का सबसे अच्छा जवाब नहीं हो सकता है (क्योंकि सवाल यह था कि चेतावनी से कैसे बचा जाए, न कि इसे कैसे निष्क्रिय किया जाए), यह उत्तर Google (जैसे मेरे) से आने वाले लोग खोज सकते थे ("कैसे" इस चेतावनी को निष्क्रिय करने के लिए ")। तो मैं +1 देता हूं, आपके उत्तर के लिए धन्यवाद!

— मोजबोज

Answer 9

मैक्रो-कम और पोर्टेबल तरीका एक या अधिक मापदंडों को अप्रयुक्त घोषित करने के लिए :

template <typename... Args> inline void unused(Args&&...) {}

int main(int argc, char* argv[])
{
    unused(argc, argv);
    return 0;
}

Comments

बहुत अच्छा है, लेकिन ध्यान दें कि इसके लिए C ++ 11 (या निश्चित रूप से नया) की आवश्यकता है।

— पॉल आर

मैंने इस उत्तर को इसलिए वोट दिया क्योंकि मैं चेतावनी से छुटकारा पाने के लिए संकलन समय (टेम्पलेट्स का उपयोग करके) का बलिदान नहीं करना चाहता।

— कोनराड क्लेन

@KonradKleine: संभवत: कितना संकलन समय यह उपभोग कर सकता है? अपने कंप्यूटर पर परीक्षण, मैं इन अप्रयुक्त () कॉल के एक हजार को दूसरे के दसवें हिस्से में निष्पादित कर सकता हूं।

— डैनियल मैक्लॉरी

@DanielMcLaury यह सिर्फ मेरा अनुमान था और मैंने कोई प्रयोग नहीं किया है।

— कोनराड क्लेन

Answer 10

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

एक तरीका यह हो सकता है कि अपने मापदंडों को किसी प्रकार के तर्क वर्ग में एक साथ रखा जाए। आप तब चर का एक सबसेट (अपने असाइनमेंट 0 के बराबर) का उपयोग कर सकते हैं या प्रत्येक प्लेटफ़ॉर्म पर उस तर्क वर्ग के अलग-अलग विशेषज्ञताओं का उपयोग कर सकते हैं। यह हालांकि इसके लायक नहीं हो सकता है, आपको यह विश्लेषण करने की आवश्यकता है कि क्या यह फिट होगा।

यदि आप असंभव टेम्पलेट पढ़ सकते हैं, तो आपको "असाधारण C ++" पुस्तक में उन्नत सुझाव मिल सकते हैं। यदि आपके कोड को पढ़ने वाले लोग उस पुस्तक में पढ़ाए गए पागल सामान को शामिल करने के लिए अपना कौशल प्राप्त कर सकते हैं, तो आपके पास सुंदर कोड होगा जिसे आसानी से पढ़ा भी जा सकता है। कंपाइलर भी अच्छी तरह से जानते होंगे कि आप क्या कर रहे हैं (प्रीप्रोसेसिंग द्वारा सब कुछ छिपाने के बजाय)

Comments

"प्रीप्रोसेसर निर्देशों का उपयोग करना ज्यादातर समय बुराई माना जाता है।" वास्तव में? किसके द्वारा?

— ग्रीम पेरो सेप

किसी के द्वारा जो गुंजाइश की परवाह करता है, ठीक से डिबग करने में सक्षम है, या उनकी पवित्रता।

— बिल

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

— बेन डडसेटन

अति प्रयोग बुरा है, लेकिन मैं #define UNUSED(expr) (void)(expr)उचित कहूंगा ।

— जॉनीजेड

Answer 11

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

मैं मानूंगा कि आपके पास स्रोत फ़ाइलों में पूरी तरह से अलग कार्यान्वयन है। इन मामलों में आप या तो अपमानजनक पैरामीटर पर टिप्पणी कर सकते हैं या केवल पैरामीटर लिख सकते हैं।

उदाहरण:

func(int a, int b)
{
    b;
    foo(a);
}

यह गूढ़ प्रतीत हो सकता है, इसलिए UNUSED जैसे स्थूल को परिभाषित किया गया है। जिस तरह से MFC ने किया वह है:

#ifdef _DEBUG
#define UNUSED(x)
#else
#define UNUSED(x) x
#endif

इस तरह आप डिबग बिल्ड में चेतावनी को देखते हैं, सहायक हो सकता है।

Answer 12

क्या हमेशा पैरामीटर नामों पर टिप्पणी करना सुरक्षित नहीं है? अगर ऐसा नहीं है तो आप कुछ कर सकते हैं

#ifdef _MSC_VER
# define P_(n) n
#else
# define P_(n)
#endif

void ProcessOps::sendToExternalApp(
    QString sAppName, QString sImagePath,
    qreal P_(qrLeft), qreal P_(qrTop), qreal P_(qrWidth), qreal P_(qrHeight))

यह थोड़ा कम बदसूरत है।

Comments

तथ्य यह है कि परम नाम C ++ में अनिवार्य नहीं है - यह C में है - यह चेतावनी को रोकने के लिए एक मानक और आसान तरीका है।

— एपीग्रामग्राम

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

— APgramgrammer

Answer 13

मैंने इसे (void)param2चेतावनी को चुप कराने के तरीके के बजाय देखा है :

void foo(int param1, int param2)
{
    std::ignore = param2;
    bar(param1);
}

ऐसा लगता है कि C ++ 11 में जोड़ा गया था

Comments

यह कुछ कर रहा है, संकलन के बाद नजरअंदाज नहीं किया जा रहा है।

— गयउयोन चोई

Answer 14

UNREFERENCED_PARAMETER(p)काम का उपयोग कर सकता है। मुझे पता है कि यह विंडोज सिस्टम के लिए WinNT.h में परिभाषित किया गया है और आसानी से gcc के लिए भी परिभाषित किया जा सकता है (यदि यह पहले से ही नहीं है)।

UNREFERENCED PARAMETER(p) की तरह परिभाषित किया गया है

#define UNREFERENCED_PARAMETER(P)          (P)

WinNT.h में।

Answer 15

संकलक के ध्वज का उपयोग करें, उदाहरण के लिए ध्वज GCC के लिए: -Wno-unused-variable

Answer 16

आप __unusedसंकलक को यह बताने के लिए उपयोग कर सकते हैं कि चर का उपयोग नहीं किया जा सकता है।

- (void)myMethod:(__unused NSObject *)theObject    
{
    // there will be no warning about `theObject`, because you wrote `__unused`

    __unused int theInt = 0;
    // there will be no warning, but you are still able to use `theInt` in the future
}

Comments

कौन सा संकलक? क्योंकि __unusedमानक C ++ नहीं है, और बिंदु से अधिक, न तो आपने जो पोस्ट किया है ... वह उद्देश्य-सी है। तो यह उत्तर केवल विशिष्ट संकलक (ओं) के लिए वास्तव में उपयोगी है, और यह कोड को गैर-पोर्टेबल बनाता है, और वास्तव में वास्तव में मान्य नहीं है क्योंकि उपयोगकर्ता कोड के साथ शुरुआत करने वाले पहचानकर्ताओं का उपयोग करने के लिए नहीं है __, जो कार्यान्वयन के लिए आरक्षित हैं।

— अंडरस्कोर_ड

Answer 17

C ++ 11 में, यह वह समाधान है जिसका मैं उपयोग कर रहा हूं:

template<typename... Ts> inline void Unreferenced(Ts&&...) {}

int Foo(int bar) 
{
    Unreferenced(bar);
    return 0;
}

int Foo2(int bar1, int bar2) 
{
    Unreferenced(bar1, bar2);
    return 0;
}

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

यदि अतिरिक्त कोड एक समस्या है, तो आप इस घोषणा का उपयोग कर सकते हैं:

(decltype(Unreferenced(bar1, bar2)))0;

लेकिन उस बिंदु पर, एक मैक्रो बेहतर पठनीयता प्रदान करता है:

#define UNREFERENCED(...) { (decltype(Unreferenced(__VA_ARGS__)))0; }

Answer 18

यह अच्छी तरह से काम करता है लेकिन इसके लिए C ++ 11 की आवश्यकता होती है

template <typename ...Args>
void unused(Args&& ...args)
{
  (void)(sizeof...(args));
}

Comments

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

— अंडरस्कोर_ड

Answer 19

मुझे ज्यादातर प्रस्तुत जवाब स्थानीय अप्रयुक्त चर के लिए ही काम करते हैं, और अप्रयुक्त स्थिर वैश्विक चर के लिए संकलन त्रुटि का कारण होगा।

अप्रयुक्त स्थिर वैश्विक चर की चेतावनी को दबाने के लिए एक और मैक्रो की आवश्यकता है।

template <typename T>
const T* UNUSED_VARIABLE(const T& dummy) { 
    return &dummy;
}
#define UNUSED_GLOBAL_VARIABLE(x) namespace {\
    const auto dummy = UNUSED_VARIABLE(x);\
}

static int a = 0;
UNUSED_GLOBAL_VARIABLE(a);

int main ()
{
    int b = 3;
    UNUSED_VARIABLE(b);
    return 0;
}

यह काम करता है क्योंकि अनाम नामस्थान में गैर-स्थिर वैश्विक चर के लिए कोई चेतावनी नहीं दी जाएगी।

हालांकि C ++ 11 की आवश्यकता है

 g++  -Wall -O3  -std=c++11 test.cpp

Answer 20

जबरदस्त हंसी! मुझे नहीं लगता कि एसओ पर एक और सवाल है जो अराजकता से भ्रष्ट सभी विधर्मियों को प्रकट करता है कि यह बेहतर है!

C ++ 17 के लिए सभी उचित सम्मान के साथ C ++ कोर दिशानिर्देशों में एक स्पष्ट दिशानिर्देश है । AFAIR, 2009 में वापस यह विकल्प उपलब्ध था और साथ ही आज भी। और अगर कोई कहता है कि इसे Doxygen में बग माना जाता है तो Doxygen में एक बग है

Answer 21

मुझे चेतावनी के साथ आपकी समस्या नहीं दिख रही है। इसे मेथड / फंक्शन हेडर में डॉक्यूमेंट करें जो कंपाइलर xy यहां (सही) चेतावनी जारी करेगा, लेकिन प्लेटफॉर्म z के लिए थिस वैरिएबल की जरूरत है।

चेतावनी सही है, इसे बंद करने की आवश्यकता नहीं है। यह कार्यक्रम को अमान्य नहीं करता है - लेकिन यह दस्तावेज होना चाहिए, कि एक कारण है।

Comments

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

— sbi

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

— sbi

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

— टोबियास लैंगर

@ रीचर्ड: मैंने हजारों सोर्स फ़ाइलों वाली परियोजनाओं पर काम किया। यहां और वहां थोड़ी चेतावनी, यहां तक ​​कि अच्छी तरह से प्रलेखित, जल्दी से जोड़ते हैं। यहां तक ​​कि अगर आपके पास बिल्ड (सैकड़ों या हजारों के बजाय) के दौरान केवल दर्जनों चेतावनी चमकती है, तो उन्हें व्यक्तिगत रूप से देखने के लिए कि क्या वे नए हैं या दस्तावेज वाले बहुत समय लेने वाले हैं और अंत में, जीता ' टी किया जाना चाहिए। इसके बाद: शून्य चेतावनी के साथ उच्चतम संभव चेतावनी स्तर पर संकलन। आने वाली हर चेतावनी पर तुरंत गौर किया जाएगा, उसे देखा जाएगा और या तो उसे ठीक किया जाएगा।

— sbi

@ एसबीआई: आपके कंपाइलर के लिए उच्चतम चेतावनी स्तर पर टरबाइनिंग स्थिर कोड विश्लेषण का कुछ रूप है। स्टेटिक कोड विश्लेषण सिर्फ इसे निष्पादित किए बिना कोड को पढ़ रहा है और इससे जानकारी काट रहा है। यह वही है जो संकलक करता है जब वह चेतावनियों के लिए अपने नियमों की जाँच करता है।

— टोबियास लैंगनर