Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Rob Stewart (rstewart_at_[hidden])
Date: 2018-11-22 00:02:52

On November 19, 2018 4:01:45 PM EST, Edward Diener via Boost <boost_at_[hidden]> wrote:
>
> Warning free is a nice ideal, but the truth is more complicated. Many 
> warnings are not really about possible coding mishaps but about a sort
> of lint-like standard which compilers now want to enforce and have 
> nothing to do with correct C++ code. Other warnings are simply 
> erroneous, as is prevalent most everywhere in the current default VC++
>  preprocessor. Eliminate even the first class of warnings is often a 
> fool's errand AFAIAC. All one ends up doing is adding completely 
> unnecessary code restrictions to what is perfectly acceptable C++
> code. 

That's a broad claim not generally borne out in my experience.

> A typical example is some variable whose name hides a variable in an 
> outer scope. This is perfectly acceptable C++ code but now many 
> compilers issue a warning when this happens. I object to having to
> worry  about coming up with a unique name to all variables in whatever
> scope in  some translation unit just to avoid such a warning.

That warning is not to enforce some notion of how code should be written. It seeks to highlight a certain class of errors. You may have been certain that the reuse of a name is valid when writing the code, but anyone including you at a later time, may be bitten by a subsequent change to the code.

If an intervening declaration is removed, perhaps unintentionally as the result of other editing, later code referring to that formally reused name will suddenly refer to the earlier declaration. The resulting code may compile, but will surely not be what was intended.

Another error that warning helps with is when a name is reused and a maintainer sees an earlier, but not a latter declaration of the reused identifier. The code may compile, yet not work as the maintainer intended.

You may argue that testing should reveal the resulting problems, but test coverage is rarely so complete as to reliably account for all cases. Renaming the variables will prevent those problems, though you do have to invent unique names.

> This process of 
> warnings enforcing coding standards goes on and on and I do not think
> it is possible, or advisable timewise, to spend unnecessary time pleasing
> every compiler's notion of what these lint-like warnings entail. I am 
> not against spending time eliminating warnings when the warning itself
> points top some loose use of C++. But I am against spending time on 
> eliminating warnings when the warning is just some lint-like alarm
> over  what might be an error but is perfectly normal and
> acceptable C++ code.

Preventing possible errors is a worthwhile goal. Such warnings, at least a subset of them, can be helpful. There are, of course, warnings that border on the ridiculous, but don't ignore the value of the majority.

--
Rob
(Sent from my portable computation device.)