Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-11-26 15:41:23

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Marshall Clow via Boost
> Sent: 26 November 2018 14:44
> To: boost_at_[hidden] List
> Cc: Marshall Clow; eldiener_at_[hidden]
> Subject: Re: [boost] Current Guidance on Compiler Warnings?
> 
> On Wed, Nov 21, 2018 at 4:10 PM Rob Stewart via Boost <boost_at_[hidden]>
> 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.
> >
> 
> This is a broad claim borne out by my experience.
> [ Note - I'm a fan of most warnings. Some of them, though, should DIAF ]
> 
> For example, should the following code cause a warning to be emitted?
> 
>     auto p = std::make_unique<unsigned char>(0);
> 
> At least one popular compiler warns on this code, complaining about a
> truncation from int --> unsigned char, and a possible loss of data.
> 
> We spent a lot of time and effort in Boost.DateTime with this.
> See https://github.com/boostorg/date_time/pull/50 and others.

Indeed - I think I first moaned about it so long, long ago that I had forgotten about it :-(

But all this language lawyery is missing what I think it the most important point:

*Documenting* that this issue has been considered.

If the programmer knows that he (or either sex, if any ***) knows something that the compiler doesn't, may not know, or cannot know,
so that bad things cannot happen, he needs to write a comment to record this.

*How* the warning is quieted is then less important, but I favour a very local disable~~~.

Paul

*** - it might even be written by a computer, and I suspect that they are gender-fluid ;-)

~~~  A reason to prefer static_cast might be that some compilers do not permit fine-grained enough disabling of warnings?

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]