3 ms·

>And I'd rather keep the library warning free instead of telling the users to switch warnings off. Why not push/pop warnings to ignore in the library? _Prag

>And I'd rather keep the library warning free instead of telling the users to switch warnings off. Why not push/pop warnings to ignore in the library? _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored \"-Wshadow\"") int a = 1; { int a = 2; } _Pragma("GCC diagnostic pop")

kevin_thibedeau 1y ago
This sort of thing is better set in CMake or equivalent with file specific flags to disable diagnostics. Then you don't have non-portable cruft littering the code, you don't have to touch third party code, and there is a more centralized accounting of what marginal code you're hacking around. The loss of specificity is rarely going to be a problem.
- cperciva 1y ago
  If you disable warnings in your makefile, you'll lose them for the entire C file. Pragma warnings as above allow them to be disabled for just the problematic code in question.
- einpoklum 1y ago
  > with file specific flags But you don't want to disable warnings throughout the file, just locally. > Then you don't have non-portable cruft littering the code, You can make it perfectly portable, with a little macro work. See, ,for example: https://github.com/eyalroz/printf/blob/013db1e345cbb166a7eb758da2b4edba93ad2458/test/test_suite.cpp#L138 https://github.com/eyalroz/printf/blob/013db1e345cbb166a7eb7... (this is from the standalone-no-libc-printf-family-implementation I maintain; the library is C, the test suite is C++ but it doesn't matter for the purposes of my point here.) and that you only need to do once in your project (you can make it your own header). Even when it comes to use - you can place your warning-disabling within another macro, so that you end up only using a simple single macro for your actual code.
o11c 1y ago
This probably isn't relevant anymore, but for now-old (4.x I think) versions of GCC, there are a couple of caveats: * Some versions can only change compiler options at top level, not within a function. * I had problems with trying to push/ignore/pop a warning around an expression in a macro, since the entire thing expands at a single location.

kevin_thibedeau 1y ago

This sort of thing is better set in CMake or equivalent with file specific flags to disable diagnostics. Then you don't have non-portable cruft littering the code, you don't have to touch third party code, and there is a more centralized accounting of what marginal code you're hacking around. The loss of specificity is rarely going to be a problem.

cperciva 1y ago
If you disable warnings in your makefile, you'll lose them for the entire C file. Pragma warnings as above allow them to be disabled for just the problematic code in question.
einpoklum 1y ago
> with file specific flags But you don't want to disable warnings throughout the file, just locally. > Then you don't have non-portable cruft littering the code, You can make it perfectly portable, with a little macro work. See, ,for example: https://github.com/eyalroz/printf/blob/013db1e345cbb166a7eb758da2b4edba93ad2458/test/test_suite.cpp#L138 https://github.com/eyalroz/printf/blob/013db1e345cbb166a7eb7... (this is from the standalone-no-libc-printf-family-implementation I maintain; the library is C, the test suite is C++ but it doesn't matter for the purposes of my point here.) and that you only need to do once in your project (you can make it your own header). Even when it comes to use - you can place your warning-disabling within another macro, so that you end up only using a simple single macro for your actual code.

o11c 1y ago

This probably isn't relevant anymore, but for now-old (4.x I think) versions of GCC, there are a couple of caveats: * Some versions can only change compiler options at top level, not within a function. * I had problems with trying to push/ignore/pop a warning around an expression in a macro, since the entire thing expands at a single location.