AMDG DE wrote:
on 16.03.2010 at 10:25 Emil Dotchevski wrote :
I think that the solution is to disable such warnings in release builds. They serve no purpose other than to tell you that assert did what it was supposed to do in release.
MSVC has a similar warning, the one that says "removed unreachable code" which tells you that the optimizer deadstripped code that could not be executed anyway. How would you deal with that warning, add casts until the optimizer is sufficiently confused? :)
one smart man (whom i have reasons to trust) said once that code must compile with no warnings at the highest warning level
A hard requirement is too strict. Some warnings are sufficiently insane that the only reasonable solution is to suppress them, and the suppression cannot always be limited to a small section of code. Warnings are warnings and not errors, because the code that the compiler warns about can be just fine and can be the best way to accomplish the task. Compilers are not infallible.
i think this is especially true about code that you give away (libs, etc.)
the code you acquire and expect it to work right out of the box may confuse you with warnings and waste your time while figuring out i believe this is especially true about novice programmers
pushing\popping warnings in EVERY source file is not an option imho
Oh, isn't it? There are quite a few Boost libraries that do #include <boost/library/disable_warnings.hpp> ... #include <boost/library/enable_warnings.hpp>
so yes, leaving unreachable code is a bad habit (imho) i would restructure code not to cause any warnings if possible (it is almost always so)
Leaving unreachable code in templates is sometimes unavoidable. In Christ, Steven Watanabe