The C++ logo, by Jeremy Kratz, licensed under CC0 1.0 Universal

Toolbox of a GNU/Linux C++ programmer


3 - 4 minutes read, 840 words
Categories: build system c c++ shell version control systems
Keywords: browser build system c c++ catch2 clang clang-tidy cmake compiler explorer cppcheck cygwin gcc linux make perf sh shell test valgrind version control systems vim

After writing about a minimal C++ development environment, I could not help but think about all the tools I normally use/used at least once/would like to use when programming on a GNU/Linux system.

Also, sometimes I read about a Tool and would like to try it out. Maybe because I do not have enough time or am working on another platform, I do not get the chance to try it out and forget about it.

So this is it, a page that enlists useful tools for C++ development under a GNU/Linux system.

Note that most of the presented tools can be used also for other programming languages, especially C.

Compilers

While one does not need to use more than one compiler, even when developing a specific application for a specific platform, using more than one compiler has multiple advantages.

  • different compilers have different diagnostic for finding different types of errors

  • it helps to avoid using by accident a compiler extensions, unless those are supported by all compilers

  • it helps to pinpoint bugs/limitations of a given compiler

  • reduce risk of writing code that would break when upgrading the compiler to a newer version

Static analyzers

Source code analyzers

The compiler can also be used as a static analyzer. Most compilers also have a whole set of flags for enabling or disabling particular checks. While it surely makes sense to check what compiler warnings are appropriate, sometimes it is easier to just execute a separate program and see if it reports something interesting.

Compared to other analyzers, as far as I know, clang-tidy is the only tool able to automatically change the offending code.

Post-build static analyzers

When talking about static analyzers, we normally talk about analyzing the source code. Sometimes it is easier to look at the generated code to gather information.

Runtime Analyzers

Valgrind is probably the most powerful tool at disposal when searching for different types of bugs (leaks, race conditions, …​) that do not require instrumenting the binary, even if it might have a big overhead. If it is acceptable to recompile the program (and eventually its dependencies), the sanitizers is probably the best alternative.

Test tools

Every runtime analyzer is a testing tool and one of the best. Without writing a single line of code, they can find even bugs that are hard to reproduce or notice (the same holds actually for static analyzers).

There are other tools able to find bugs semi-automatically, like

Formatters

Contrary to other development tools, were using more than one of the same category generally is a good thing, using more than one formatter is not advisable.

Currently, clang-format seems the most well-maintained formatter, as it recognizes all C++ features (lambda expression, macros, keywords added in a later revision of the language like constexpr, …​)

Contrary to static analyzers, where it is possible to ignore wrong warnings, a formatter that formats (or even breaks) the code wrongly because it does not recognize some language feature is more problematic. When formatting code, it is normally wanted that (nearly) everything is formatted accordingly. If one needs to add too many exceptions, the outcome will be that the code is not formatted uniformly.

Special mention to editorconfig, as it is not a formatter, but a file format understood by multiple editors (eventually through plugins) for unifying preferences based on file types.

As it only specifies simple rules likes

  • line endings

  • if inserting newline at the end of the file

  • charset

  • if tabs should be replaced by spaces or not

(and eventually editor-specific extensions) it can be probably used together with any formatter

Other

A set of tools that are not necessarily directly related to C++, but used frequently


Do you want to share your opinion? Or is there an error, some parts that are not clear enough?

You can contact me here.