I agree with you, I understand the desire of the industry to institute demonstrable measures of quality in the face of mounting costs associated with certifying code. Or should I say, the increasing size and complexity of code that they want to certify. But the result is often a cast that is placed without good understanding of the context. I'd love to see more emphasis tools like coverity, klockwork, that look for less obvious issues, and languages like Rust that avoid common issues with more rigorous syntax. At least with boost.org we have the benefit of some very good maintainers to act as gatekeepers and avoid the worst of these uninformed revision. On Mon, 19 Nov 2018 at 15:03, Emil Dotchevski via Boost < boost@lists.boost.org> wrote:
On Mon, Nov 19, 2018 at 11:21 AM Brian Kuhl via Boost < boost@lists.boost.org> 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.
In that context there are probably legal reason for zero-warning policy, but it is not true that lack of warnings means fewer errors, in fact it could easily lead to more errors. For example warnings about implicit conversions are frequently "fixed" by replacing the implicit conversion with explicit conversion (cast). But the two are semantically very different, and therefore one of them is incorrect, and very likely that is the explicit one.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost