3 ms·
> If a warning message is considered not fixable, or not desirable to fix, it’s preferable to remove the associated flag from the build chain. I like to use di
by deogeo 8y ago
> If a warning message is considered not fixable, or not desirable to fix, it’s preferable to remove the associated flag from the build chain.
I like to use diagnostic pragmas (https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html) in the vanishingly rare cases where I can't fix the cause of a warning.
- berti 8y agoThis unfortunately gets messy when you're targeting multiple compilers, and in some cases multiple versions of the same compiler.
- deogeo 8y agoAt least clang has it covered: https://clang.llvm.org/docs/UsersManual.html#pragma-gcc-diagnostic https://clang.llvm.org/docs/UsersManual.html#pragma-gcc-diag... Don't know what the situation is on MS's and Intel's compilers.
- raptorfactor 8y agoThe same functionality is available: https://docs.microsoft.com/en-us/cpp/preprocessor/warning?view=vs-2017 https://docs.microsoft.com/en-us/cpp/preprocessor/warning?vi...
- MaulingMonkey 8y agoAnd you can use _Pragma / __pragma to hide them inside (conditional) macros without #ifdefing up every call site. There are still edge cases where you can't sanely scope them relating to when templates are evaluated, being unable to use the pragmas at arbitrary points of an expression, warnings that don't respect the warning flags properly, etc. - but it works most of the time. That said, for warnings with high false positives and low value true positives, I'll just globally suppress the warning.
- loeg 8y agoWorks well if your only targets are GCC and Clang. For building across several platforms with other compilers, you could just manipulate the flags globally on those other compilers without giving up high levels and specificity of warnings on gcc/clang.