Re: [boost] Current Guidance on Compiler Warnings?

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