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 02:04:20

On November 21, 2018 8:00:47 PM EST, Edward Diener via Boost <boost_at_[hidden]> wrote:
> On 11/21/2018 7:02 PM, Rob Stewart via Boost wrote:
> 
> > 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.

C++ does that already and we use it to advantage. It's a strongly typed language with const and volatile modifiers, rvalue overloading, etc. We use those tools to control or restrict what can be done with our code.

Choosing to code in a way that prevents or reduces the chance of error is de rigeur in C++. If everyone followed your philosophy, we'd use raw pointers to track memory allocations, etc. Who needs RAII to manage resource lifetime if the code is known to be correct, right?

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

I've been using C++ for decades quite happily; I don't need another language to satisfy such a trumped-up need. While the language allows many (potentially) unsafe things, I choose to use a safe subset of the language, like so many others.

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

Inaccurate. When one can simple take steps to prevent potential errors, it's unwise not to do so.

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

That's a straw man argument. The issue in question only arises when names in an inner scope hide those in an outer scope.

> Torture yourself with such absurdities, in the name of safe
> programming  no doubt, but I want none of it.

I don't care for hyperbolic discussions. I've made my point. You're welcome to learn from it or ignore it. I hope others will benefit.

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

Well, at least we agree on that.

> Where we disagree sharply is the tedious elimination of warnings on 
> perfectly correct code as a path to that prevention.

The point you've missed is that you generally cannot be certain that a warning is benign without scrutinizing the code in question. I'd prefer to do that just once, so after ensuring the code is correct, I also take steps to eliminate the warning. That allows me to focus on new warnings rather than try to remember which to ignore or to miss new warnings buried amidst so many others.

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

I disagree, obviously.

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