Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-11-22 01:00:47

On 11/21/2018 7:02 PM, Rob Stewart via Boost wrote:
> 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.

Your response is typical of those programmers who seek a language that 
will keep programmers from making mistakes by restrictions on what the 
language should allow. That language you seek is not C++ thank god.
Whether the restriction is an actual rule of that language or whether 
the restriction is a warning, which others tell me I must eliminate, 
makes little difference to me. Try another language like Ada or one of 
those many safer languages whose "safe" rules make it much more tedious 
to program than C++.

> 
> 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.

That is a red herring. Any code may compile and not do what was 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.
> 

Sorry, programming in a language where every variable in a TU, even the 
most trivial, has to have some utterly unique name in that TU, and whose 
names I am expected to all know and keep track of, is not for me. 
Torture yourself with such absurdities, in the name of safe programming 
no doubt, but I want none of it.

>> 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.

I agree with you that preventing possible errors is a worthwhile goal. 
Where we disagree sharply is the tedious elimination of warnings on 
perfectly correct code as a path to that prevention. It is a huge waste 
of time, and totally unnecessary to boot, to change code to prevent 
warnings when the code is correct in doing what it aims to accomplish. 
Programmers have much better and harder things to do in the design and 
implementation of their ideas and algorithms than to worry about what 
any compiler implementation thinks should be a reason for issuing 
warnings. I am not saying that all warnings should be unheeded. I am 
saying that trying to fix every warning for every compiler, because some 
end user insists that he wants to compile with the highest level of 
warnings and never see any warnings, is not a practical way of writing 
software.

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