| 750 | With GCC, it is more difficult to deal with warnings because there is no way (yet) '''locally''' silence individual warnings. It is considered important not to leave warnings switched off when meeting user code. This is an unresolved difficulty. |
| 751 | |
| 752 | On the other hand, the number of unhelpful warnings seems fewer. |
| 753 | |
| 754 | So more emphasis should be placed on fixing warnings, for example using static_cast, or providing missing items. |
| 755 | |
| 756 | For a particular file, |
| 757 | |
| 758 | #pragma GCC system_ // No warnings from all this file, considered a system header. |
| 759 | |
| 760 | or option --isystem |
| 761 | |
| 762 | The -isystem command line option adds its argument to the list of directories to search for headers, just like -I. Any headers found in that directory will be considered system headers. |
| 763 | |
| 764 | -Wsystem-headers |
| 765 | |
| 766 | is effective until the end of the file. |
| 767 | |
| 768 | Print warning messages for constructs found in system header files. Warnings from system headers are normally suppressed, on the assumption that they usually do not indicate real problems and would only make the compiler output harder to read. Using this command line option tells GCC to emit warnings from system headers as if they occurred in user code. However, note that using -Wall in conjunction with this option will not warn about unknown pragmas in system headers—for that, -Wunknown-pragmas must also be used. |
| 769 | |
| 770 | The GCC docs say: "Also, while it is syntactically valid to put these pragmas anywhere in your sources, the only supported location for them is before any data or functions are defined. Doing otherwise may result in unpredictable results depending on how the optimizer manages your sources." |
| 771 | |
| 772 | This might only mean you can't use them inside functions or class definitions, but it seems to imply that using them after a function definition leads to undefined behavior. Thus, even if we knew what setting to turn the warning back to (perhaps the warning wasn't enabled in the first place!), we might not be able to turn them back on. |
| 773 | |
| 774 | <toolset>gcc:<cxxflags>-fdiagnostics-show-option # find out which options controls this warning (GCC >= 4.3) |
| 775 | |
| 776 | #if defined(__GNUC__) // GCC 4.3 and higher. |
| 777 | #pragma GCC diagnostic ignored "-Wdeprecated-declarations" |
| 778 | #endif |
| 779 | |
| 780 | But that doesn't quite work, how do you know that the user wants -Wdeprecated-declarations to be set to "warning" after the include? |
| 781 | Could be the user has disabled that one on the command line, in which case if we turn it back on, that's as annoying for the end user as warnings from Boost! There was a time when some MSVC std lib headers behaved like that, and believe me it was *seriously* annoying :-( |
| 782 | |
| 783 | -Wall |
| 784 | This enables all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros. This also enables some language-specific warnings described in C++ Dialect Options and Objective-C and Objective-C++ Dialect Options. |
| 785 | |
| 786 | -Wall turns on the following warning flags: |
| 787 | |
| 788 | -Waddress |
| 789 | -Warray-bounds (only with -O2) |
| 790 | -Wc++0x-compat |
| 791 | -Wchar-subscripts |
| 792 | -Wimplicit-int |
| 793 | -Wimplicit-function-declaration |
| 794 | -Wcomment |
| 795 | -Wformat |
| 796 | -Wmain (only for C/ObjC and unless -ffreestanding) |
| 797 | -Wmissing-braces |
| 798 | -Wnonnull |
| 799 | -Wparentheses |
| 800 | -Wpointer-sign |
| 801 | -Wreorder |
| 802 | -Wreturn-type |
| 803 | -Wsequence-point |
| 804 | -Wsign-compare (only in C++) |
| 805 | -Wstrict-aliasing |
| 806 | -Wstrict-overflow=1 |
| 807 | -Wswitch |
| 808 | -Wtrigraphs |
| 809 | -Wuninitialized |
| 810 | -Wunknown-pragmas |
| 811 | -Wunused-function |
| 812 | -Wunused-label |
| 813 | -Wunused-value |
| 814 | -Wunused-variable |
| 815 | -Wvolatile-register-var |
| 816 | |
| 817 | |
| 818 | |
| 819 | Note that some warning flags are not implied by -Wall. Some of them warn about constructions that users generally do not consider questionable, but which occasionally you might wish to check for; others warn about constructions that are necessary or hard to avoid in some cases, and there is no simple way to modify the code to suppress the warning. Some of them are enabled by -Wextra but many of them must be enabled individually. |
| 820 | -Wextra |
| 821 | This enables some extra warning flags that are not enabled by -Wall. (This option used to be called -W. The older name is still supported, but the newer name is more descriptive.) |
| 822 | |
| 823 | -Wclobbered |
| 824 | -Wempty-body |
| 825 | -Wignored-qualifiers |
| 826 | -Wmissing-field-initializers |
| 827 | -Wmissing-parameter-type (C only) |
| 828 | -Wold-style-declaration (C only) |
| 829 | -Woverride-init |
| 830 | -Wsign-compare |
| 831 | -Wtype-limits |
| 832 | -Wuninitialized |
| 833 | -Wunused-parameter (only with -Wunused or -Wall) |
| 834 | |
| 835 | |
| 836 | The option -Wextra also prints warning messages for the following cases: |
| 837 | |
| 838 | * A pointer is compared against integer zero with `<', `<=', `>', or `>='. |
| 839 | * (C++ only) An enumerator and a non-enumerator both appear in a conditional expression. |
| 840 | * (C++ only) Ambiguous virtual bases. |
| 841 | * (C++ only) Subscripting an array which has been declared `register'. |
| 842 | * (C++ only) Taking the address of a variable which has been declared `register'. |
| 843 | * (C++ only) A base class is not initialized in a derived class' copy constructor. |
| 844 | |
| 845 | |
| 846 | More information needed here! |
| 847 | |