Another cool feature in the Visual Studio 2012 C++ compiler is the revamped code analysis rule sets and brand new UI for configuring them. This is not just the simple /analyze switch we all know and love since Visual Studio 2005 anymore.

To get a general impression of the UI changes, open a C++ project’s properties and check out the Code Analysis node. You’ll be able to review the rule set that runs on your project and optionally enable/disable specific warnings. Check out some of these rules:

Specifically, I’d like to focus on the new concurrency analysis rules (in the C261nn range). These rules—like most C++ code analysis rules—rely on annotations placed in the source code that instruct the analysis engine what to look for. For example, you can place a _Guarded_by_(X) annotation on a variable to indicate that access to it should always be protected by a lock X.

Carefully placing these annotations all over your source code might seem like an excessive burden, but this is an investment that pays off greatly when you later introduce subtle bugs. Consider the following simple example of an Account class, whose balance field is protected by the critical section lock:

class Account {
private:
  CRITICAL_SECTION lock;
  _Guarded_by_(lock) double balance;
public:
  //…constructor and other methods omitted for brevity
  void withdraw(double amount) {
    EnterCriticalSection(&lock);
    balance –= amount;
    LeaveCriticalSection(&lock);
  }
};

Sounds easy. Now you have a new requirement, to make sure that the balance is not negative before withdrawing. You make the following careless change, and oops—there’s a race condition in your class!

bool withdraw(double amount) {
  if (balance < 0.0) return false; //oops!
  EnterCriticalSection(&lock);
  balance –= amount;
  LeaveCriticalSection(&lock);
  return true;
}

The code analysis engine will detect this problem and report it immediately:

There are many other use cases for these concurrency warnings: mark a variable with _Interlocked_ and the compiler will make sure it’s always accessed with an interlocked operation; failure to release a lock in some code path will always be triggered:

…and there’s the holy grail of deadlock detection, too, if you incorporate lock leveling into your code with the _Create_lock_level_, _Lock_level_order_ and _Has_lock_level_ annotations. Here’s an example:

This is definitely a step in the right direction for automatic code analysis in C++. You should at least once try running all the rules on your existing code base—you might be surprised how many nasty bugs code analysis could unveil!