Questa risposta e i commenti aggiunti mostrano un modo per disabilitare diversi avvisi del compilatore usando #pragma direttive.
Perché uno vorrebbe farlo? Di solito gli avvertimenti ci sono per una ragione, e ho sempre pensato che fossero buone ragioni. C'è un "caso valido" in cui gli avvertimenti dovrebbero essere disabilitati? In questo momento non riesco a pensare a nessuno, ma forse sono solo io.
Ho sempre avuto solo una situazione in cui ho disabilitato un avvertimento. Considero gli errori di avviso quindi non rilascerei normalmente con avvisi. Tuttavia, durante lo sviluppo di un'API presso un cliente, ho affrontato il problema che un metodo che era necessario in una fase di migrazione da parte di un'applicazione e che nessun altro avrebbe dovuto mai utilizzare doveva essere incluso nella libreria.
Il modo migliore che ho trovato per dire a tutti gli utenti dell'API che non dovevano chiamare questo metodo era contrassegnarlo come obsoleto. Ciò, tuttavia, significava che l'unico caso d'uso valido era contrassegnato come avviso di compilazione.
Eric Lippert ha scritto alcuni post sugli avvertimenti in cui troverai informazioni su come il team del compilatore pensa agli avvertimenti.
Non usato l'uso delle direttive non è contrassegnato con gli avvisi
Ecco alcuni avvisi in cui la documentazione fornisce i motivi per cui potresti volerli disabilitare:
Altri esempi includono avvertimenti sull'utilizzo di metodi deprecati se sai che vuoi ancora utilizzare il vecchio metodo o avere membri privati che non vengono mai letti localmente, ma con una riflessione.
Nella mia esperienza C # ha meno bisogno di disabilitare gli avvisi rispetto ad altri linguaggi come C ++. Questo in gran parte perché, come dice Eric Lippert nel suo blog ," cercano di riservare avvisi solo per quelle situazioni in cui possiamo dire con certezza che il codice è rotto, fuorviante o inutile. "
Un esempio in C che incontro regolarmente con varianti:
int doSomething(int argument1)
{
#ifdef HARDWARE_TYPE_A
performAction(argument1);
#else
displayNotSupportedMessage();
#endif
}
L'argomento è rilevante solo su alcune piattaforme, ma su quelle in cui non è rilevante il mio compilatore si lamenterà, e dal momento che ho gli avvisi convertiti in errori che impedirà la creazione.
La conversione degli avvisi in errori richiede praticamente un escape hatch per "non questo, lo so meglio del compilatore in questo caso".
Molte librerie Java indispensabili non sono mai state aggiornate per eliminare la necessità di tipi non sicuri. La soppressione di tali avvisi è necessaria in modo che altri avvertimenti più importanti vengano rilevati e corretti.
Realizzo lavori incorporati e mi sembra di ricordare un paio di volte in cui ho disattivato gli avvisi perché stavo facendo qualcosa che sembrava inutile al compilatore, ma che in realtà aveva effetti reali nell'hardware.
L'unica altra volta è quando sto lavorando su basi di codici con idee disparate su qualche struttura dati (come come rappresentare array di byte - char o unsigned char?). In questi casi, potrei disabilitare gli avvisi perché l'alternativa è passare giorni interi a passare il codice e modificare una porzione o inserire centinaia di calchi.
Ci sono parecchi motivi per disattivare selettivamente gli avvisi del compilatore, anche per i progetti che si sforzano di ottenere le migliori pratiche.
-isystem , ci sono casi in cui le differenze nelle intestazioni di sistema causano avvertimenti che possono essere ignorati (forse una funzione ha un valore di ritorno firmato su un sistema ma non un altro), attivando gli avvisi di -Wsign-compare . -Wsign-conversion eg). (void)arg1; (void)arg2; (void)arg3; ... nel corpo di ogni stub function. -Wunused-parameter in questo caso. Tieni presente che in tutti questi esempi, la disattivazione degli avvisi non significa nascondere bug reali, ad esempio: -Wredundant-decls , -Wunused-parameter , -Wdouble-promotion , forse -Wpedantic ... e che tu sai cosa stai facendo!
Valido o no, a volte viene fatto per bypassare la direttiva "trattare gli avvertimenti come errori" sul build server.
Oltre a questo non riesco a pensare a nessuno dei due. Gli avvertimenti disabilitati sono di solito un segno di un "brutto presentimento" ...
L'ultima volta che abbiamo disattivato alcuni avvisi, era perché uno stagista ci aveva lasciato con un codice errato. Ho funzionato molto meglio, con chiari limiti di conversione che sostituiscono la rappresentazione casuale dei dati.
Nel frattempo, dovevamo compilarlo e volevamo l'opzione "warnings is errors", quindi abbiamo soppresso alcuni degli avvertimenti.
Attualmente, l'unico avviso che ignoro è
warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
Perché microsoft non implementa le specifiche C ++ (la documentazione dice anche che non lo fanno!) e consente alle funzioni di dichiarare specifici lanci e tutte le funzioni possono solo lanciare throw () o throw (...), cioè niente o tutto.
Da HelpViewer 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.