Closed zwimer closed 2 years ago
Wouldn't better to remove all warnings from the backward-cpp header instead?
Certainly for some things, but there are hundreds of warning flags; this allows developers with obscure ones we don't remove warnings for to compile with them. One example (from my use case) is -Wswitch-default
; this is not enabled by -Wall
nor -Wextra
, it is an extra flag I prefer to use that causes issues (because of -Werror
) when I compile with this header.
From my perspective, the alternative is going through this list and covering every possibility, then repeating for clang and MSVC. I don't see this as a viable option, however.
You don't have to fix it for the whole world. But for whichever warning configuration you are using. The default clause for switch statements is not a bad thing for example.
Do you think some warning configuration could conflict? That is, the code wouldn't possibly compile for two different warning flags at once or something like that.
I can change this as desired, if you want the original function to stay the same I can make a second
add_backward_as_system
function or something else; I did it this was to prevent code duplication going forward but I can edit this if you want something different.The benefit of allowing include as system is that it allows gcc to ignore warnings generated from this code. For example, if compiling with
-Wall
, you getW-sign-compare
, as shown here. Thus, compiling with-Wall -Werror
may lead to a failure to compile since there are a few sign switches in this code, such as here. By including as a system error, warnings such as this are not emitted and thus never become errors.In other words, this PR allows people to compile their code with
-Werror
and whichever warning flags they desire without having to worry about how those flags might interact withbackend.hpp
.