Toolbox of a GNU/Linux C++ programmer
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 diagnostics for finding different types of errors
-
it helps to avoid using accidentally a compiler extension unless it is supported by all compilers
-
it helps to pinpoint bugs/limitations of a given compiler
-
reduce the 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.
-
code complexity counters
-
flawfinder, probably superseded by compiler warnings and other analyzers
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.
-
objdump
,readelf
,strings
, … (most can be found with a GCC toolchain, or a package equivalent to binutils) -
pfunct, pahole and other from the dwarfes package
Runtime Analyzers
-
check compilers and library flags (debug mode)
-
NDEBUG
andassert
-
-
ldd
-
debuggers
-
-
AddressSanitizer (ASAN) and _GLIBCXX_SANITIZE_VECTOR
-
-
perf with flamegraphs
-
tracing programs
-
ftrace
-
ktrace
-
-
coverage
Valgrind is probably the most powerful tool at your 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), sanitizers are 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
-
property testing frameworks/test generators
-
test suites
Formatters
Contrary to other development tools, where using more than one of the same category generally is a good thing, using more than one code formatter is not advisable.
Currently, clang-format seems the most well-maintained code 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 a 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
-
A vim-like editor, especially because of macros and it’s ubiquity.
-
text manipulation programs (
awk
,sed
,grep
,cut
, …) -
bash-like or bash-compatible shell
-
tons of undocumented scripts and other little programs, configurations, and hacks with various degrees of utility
-
build systems
Do you want to share your opinion? Or is there an error, some parts that are not clear enough?
You can contact me anytime.