On 11/19/2018 2:20 PM, Brian Kuhl via Boost wrote:
I'd like to confirm the guidance on Warnings I find here https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines is still considered current?
context ...
At Wind River we are in the process of working with Boost 1.68 and VxWorks 7 (with Dinkum 7.00 with and Clang 6.0 for ARM and IA boards and GCC 8.1 for PowerPC ) with the hope of bundling Boost with our product.
Many of our customers make certified systems ( Planes, Trains, Medical Equipment, Factory Automation, etc. ) and the trend in theses industries is to be pedantic about eliminating all compiler warnings.
While we have not traditionally required zero warnings in open source code shipped with our product, there is pressure on us to move in that direction, and as result we will probably be contributing pull requests specifically to fix or suppress compiler warnings over the coming years.
I'd like to establish clear guidelines for my team as to what is an appropriate "coding standard" for Boost in regards to compiler warnings. While it is simple to say, everything displayed by -Wall, in practice there are many edge cases, e.g. is an unused parameter acceptable in test code? So I'd like to get the maintainers guidance.
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. 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. 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.
Many thanks
Brian Kuhl