Re: [boost] Current Guidance on Compiler Warnings?

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Marshall Clow via Boost Sent: 26 November 2018 14:44 To: boost@lists.boost.org List Cc: Marshall Clow; eldiener@tropicsoft.com Subject: Re: [boost] Current Guidance on Compiler Warnings?

On Wed, Nov 21, 2018 at 4:10 PM Rob Stewart via Boost wrote:

...

On November 19, 2018 4:01:45 PM EST, Edward Diener via Boost < boost@lists.boost.org> 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 +44 (0) 1539 561830