Re: [boost] Compiler warnings after boost update

Subject: Re: [boost] Compiler warnings after boost update
From: Auer, Jens (jens.auer_at_[hidden])
Date: 2015-09-25 05:02:58

Hi John,

> This is tricky: I do try and keep my stuff warning free - but every new compiler
> release introduces warnings for things that weren't considered issues before
> (meanwhile things that I feel really should be warnings - like incorrect use of
> noexcept specifications remain curiously diagnostic free).  Then you have to ask -
> which compiler? MSVC and GCC warnings are generally fixable - though I have
> certainly come up against warnings that seem to be unsilenceable no matter what
> you do.  Intel is another matter - this generally produces pages and pages of
> "remarks"
> that aren't even warnings as such.
> 
> BTW we do have some guidance on this:
> https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines
> 
> And a now completely out of date effort to make Boost warning free:
> https://svn.boost.org/trac/boost/wiki/WarningFixes
>
Just to be clear: I am not proposing to start a huge effort to be fix all warnings. I think that is not going to happen because there are more important things to spend the time on. I can live with the Isystem work-around, but it feels fishy that a library such as Boost ignores the recommendation to compile with highest warning levels.

My idea would be to
1. define a set of reference compilers and versions, e.g. gcc, msvc
2. define a warning level. The document you quoted says this should be /W4 for MSVC and -Wall -Wpedantic for gcc
3. new code and changes of old code shall be warning free w.r.t. to the above definition. This can be checked automatically. We use SonarQube for this, but it needs a central build server which somebody has to host. I thought that boost had one, but this seems not to be the case. 
4. If a warning cannot be fixed, e.g. because it is not actually a problem, it can be silenced.

I think that this would gradually improve the situation. Most of the warnings I've seen were about old-style casts, using 0 instead of nullptr or name shadowing. 

> This might actually be easier to achieve now that we have PR's available
> as a tool.   But it's a big job for sure.
Out of curiosity: What are PR's?

Cheers,
  Jens

--
Dr. Jens Auer | CGI | Software Engineer
CGI Deutschland Ltd. & Co. KG
Rheinstraße 95 | 64295 Darmstadt | Germany
T: [phone]
jens.auer_at_[hidden]
Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben.
CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.