[This post was written by Andrew Pardoe and Neil MacIntosh]

Update: The CppCoreCheck tools are now part of VS 2017: https://blogs.msdn.microsoft.com/vcblog/2016/10/12/cppcorecheck.

Back in September at CppCon 2015 Neil announced that we would be shipping new code analysis tools for C++ that would enforce some of the rules in the C++ Core Guidelines. (A video of the talk is available here: https://www.youtube.com/watch?v=rKlHvAw1z50 and slides are available on the ISOCpp GitHub repo.)

Earlier this week we made the first set of those code analysis tools freely available as a NuGet package that can be installed by users of Visual Studio 2015 Update 1. The package currently contains checkers for the Bounds and Type profiles. Tooling for the Lifetime profile demonstrated in Herb Sutter’s plenary talk (video at https://www.youtube.com/watch?v=hEx5DNLWGgA) will be made available in a future release of the code analysis tools.

The package is named “Microsoft.CppCoreCheck”, and a direct link to the package is here: http://www.nuget.org/packages/Microsoft.CppCoreCheck.

To enable the new code analysis tools, simply install the NuGet packages to each C++ project that you want checked within Visual Studio.

The NuGet package adds an additional MSBuild targets file that gets invoked when you have code analysis enabled on your project. This targets file adds the CppCoreCheck as an additional plugin to the PREfast code analysis tool. You can enable code analysis by selecting the checkbox in the Code Analysis section of the project Properties dialog. It doesn’t matter what rule set you select–the CppCoreCheck rule sets will always run when Code Analysis is enabled.

These tools are an important first step in ensuring that users of Visual Studio can benefit from enforcement of the C++ Core Guidelines. Please note that they require Visual Studio 2015 Update 1 and will not work with earlier releases.

Here’s an example of the kind of issues that the tools will find:

void main() {     int arr[10];           // BAD, warning 26494 will be fired     int* p = arr;          // BAD, warning 26485 will be fired

    [[suppress(bounds.1)]] // This attribute suppresses Bounds rule #1     {         int* q = p + 1;    // BAD, warning 26481 would be fired         p = q++;           // BAD, warning 26481 would be fired     } }

There are a few interesting things to note here. First, let’s look at the full description of the warnings that will come from this code sample:

• 26494 is Type Rule 5: Always initialize an object.
• 26485 is Bounds Rule 3: No array to pointer decay.
• 26481 is Bounds Rule 1: Don’t use pointer arithmetic. Use span instead.

The first two warnings fire when you compile this code with the CppCoreCheck code analysis installed and activated. But the third warning doesn’t fire because of the attribute. The developer marked this code block to keep CppCoreCheck from detecting any violation of Bounds Rule 1. He could have marked the other statements to suppress Type Rule 5, or even suppressed the entire bounds profile by writing [[suppress(bounds)]] without including a specific rule number. The C++ Core Guidelines are there to help you write better and safer code but C++ is ultimately about providing the developer with the ability to do the right thing. In an instance where a rule or a profile shouldn’t be applied, it’s easy to suppress them directly in the code.  

While the code analysis tools aren’t yet open source, distributing them on NuGet means we can update them to address any issues you might find. We also look forward to adding checkers for new profiles (such as Lifetime) as they are developed in the Guidelines. Feel free to send us mail at cppcorecheck@microsoft.com with your feedback!

The NuGet package containing our analysis tools installs a subsidiary package containing Microsoft’s implementation of the Guideline Support Library (GSL). The package is also available standalone at http://www.nuget.org/packages/Microsoft.Gsl. This library is essential if you want to follow the Core Guidelines and replace use of constructs like a T*+ length pair of parameters with the span<T> type from the GSL. The GSL is open source, so if you want to take a look at the library sources, comment, or contribute, please come see us at https://github.com/Microsoft/GSL.

Finally, the C++ Core Guidelines is an open, community-based effort, and in that spirit we would also like to take this opportunity to point people to an alternative implementation of the checks for the Bounds and Type profiles. The clang-tidy developers have already included a number of checks for these profiles in the open source clang-tidy project. You can find out more about clang-tidy and their checks for the C++ Core Guidelines here: http://clang.llvm.org/extra/clang-tidy/.

We are really excited about all these first steps towards supporting enforcement of the Core Guidelines. As always, we welcome your feedback about the good and the bad with these tools and libraries so that we can keep improving on them. Let us know your thoughts at cppcorecheck@microsoft.com!