loading...

Tools for C++ Development

dwd profile image Dave Cridland ・4 min read

Tools

Since much of my life is spent in a darkened room somewhere below the sewers - or as some call it, "systems programming" - my toolset is radically different from the light and airy world of Web development, especially if I'm doing C++. C++ has a reputation as being a difficult language to work with - it's low level, complex, and it's easy to get things subtly wrong if you're not very careful.

Projects like Metre and Spiffing are projects where errors can be difficult to track down, and critical when they occur. I've ended up with a set of great tools to help avoid, and help find, bugs.

Debugging

Valgrind Logo

The most useful of these is certainly Valgrind. Valgrind emulates a processor and memory, and then tracks additional information about every byte of memory and operation. For example, its Memcheck suite handles low-level memory errors. Was this byte of memory ever initialized? If not, and we later use it, that's probably a bug. Was this byte ever freed after allocation? Was it used after freeing?

Many of these kinds of checks find errors that might not trigger an actual crash during normal tests, and maybe not even normal operations - but they're errors, and dangerous ones. So it's great to have a tool like valgrind that can trigger early on such things (and indeed fire up a debugger on the frozen process so you can investigate further).

Other analyzers Valgrind can run include checking you're locking data structures in threaded servers and all sorts. The most amazing thing is that it requires no instrumentation at all - you can run your normal builds in Valgrind.

Valgrind is Open Source, and available for Linux and Mac.

Valgrind

Static Analysis

Static Analysis is the process by which source code is examined for potential bugs before you've even run it. There are simple static analysis tools built into most compilers, but Coverity is practically psychic - it'll spot not only outright errors, but deviations from your normal usage of a function which might indicate an error. On Metre, for example, it noted I'd forgotten to check a return value (and helpfully showed me other places that I hadn't). It also noted that I'd passed variables called to and from into a function that took parameters from and to - although not a bug, I found it pretty impressive nonetheless.

Coverity is a service, and Open Source projects can use Coverity for free.

Scan Coverity

Coverity is great, but it's often simpler to have this run as part of a "normal" build locally. The Clang Static Analyzer will find all sorts of errors, though with reasonably good idiomatic C++, it shouldn't find much even the first time you try.

Part of the Open Source LLVM project.

Clang Static Analyzer

Coverage Checking

I'm a little dubious about code coverage as a simple metric - I think it can be a little too easy to equate high code coverage with high test quality.

However, LCOV and Coveralls make it pretty easy to figure out now only how good your code coverage is, but also where exactly you're lacking coverage. This means I can create test cases to exercise codepaths I find are missing. Linux COVerage is part of the Linux Test Project, and is a code coverage tool building on GCOV which all runs locally. Coveralls is a github-integrated service that works nicely with Travis.

Coveralls
LCOV

Fuzz Testing

American fuzzy lop, or simply AFL, is a fuzz tester that aims to find bad input that will crash your application. It's particularly useful for applications that are parsing formats like XML or ASN.1 - Spiffing parses both.

Most fuzz testers work by altering the input data according to known rules. AFL works by instrumenting your code just like the coverage tools above, and then using this instrumentation to tweak the input using genetic algorithms and try to explore all your code paths. If you think about what it's doing, it almost seems sinister - it's constantly feeding input into your helpless program to find new and horrible ways of crashing it.

Honestly, the only way I could see AFL being any better is if it combined Valgrind's ability to find almost-crashes.

AFL

IDE

No matter where you live in the stack, you can really benefit from a powerful development environment.

JetBrains is the company behind IDEA, Android Studio, and Kotlin. CLion is their commercial C++ IDE, and more or less makes C++ development feel like Java, with full autocompletion and on-the-fly error highlighting, as well as integrated graphical debuggers and so on.

I was never much of an IDE person until I started using it; now I find I depend on it totally. It really reduces the time between edit and run, and removes so much of the context-switching between them too. Finally, the autocompletion is good enough that I can largely forget about large chunks of the project as I work on others, keeping cognitive load free for the task at hand.

Jetbrains CLion

Others

Of course, I'm always looking for new tools... And there's a comment section right there...

Posted on by:

dwd profile

Dave Cridland

@dwd

Open source and open standards for mission-critical code.

Discussion

markdown guide