ned Productions Consulting

Technology musings by Niall Douglas
ned Productions Consulting
(an expert advice and services company based in Ireland)

Monday 11th May 2015 6.01pm

Link shared:

As part of publicising my C++ Now 2015 talk next week, here is part 5 of 20 from its accompanying Handbook of Examples of Best Practice for C++ 1114 (Boost) libraries:

5. QUALITY: Strongly consider per-commit compiling your code with static analysis tools

In Travis and Appveyor it is easy to configure a special build job which uses the clang static analyser on Linux/OS X and the MSVC static analyser on Windows. These perform lengthy additional static AST analysis tests to detect when your code is doing something stupid and the use of these is an excellent sign that the developer cares about code quality. Static analysis is perfectly suited to be run by a CI as it takes extra time to compile your program, so a CI can trundle off and do the lengthy work itself while you get on with other work.

Enabling Microsoft's static analyser is easy, simply add /analyze to the compiler command line. Your compile will take ten times longer and new warnings will appear. Note though that the MSVC static analyser is quite prone to false positives like miscounting array entries consumed. You can suppress those using the standard #pragma warning(disable: XXX) system around the offending code.

Enabling clang's static analyser is slightly harder. You'll need to replace the normal call of the compiler with whatever tool is set into the CXX environment variable by the scan-build tool. See For Boost projects, I found this script to work well:

rm -rf "$REPORTS"
git submodule update –init –recursive
cd boost-local
/usr/share/clang/scan-build-3.4/scan-build –use-analyzer=/usr/bin/clang-3.4 -o "$REPORTS" ./b2 toolset=gcc-4.7 libs/afio/test -a –test=test_all.cpp –link-test

Note that my b2 has a $HOME/user-config.jam which resets the compiler used to the value of $CXX from the environment:

import os ;
using gcc : : [ os.environ CXX ] ;

scan-build will generate a HTML report of the issues found with a pretty graphical display of the logic followed by the analyser into the $REPORTS directory. Jenkins has a plugin which can publish this HTML report for you per build, for other CIs you'll need to copy the generated files onto a website somewhere e.g. committing them to your repo under gh-pages and pushing them back to github.