|
Boost : |
Subject: Re: [boost] suggestion on assertion macros
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-16 14:23:01
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk