C++ development tools for Linux

If you are a hobby carpenter, then you might very well get by with a screwdriver only. A screwdriver can be used to drive screws into a wall, you can use it to put nails in the wall, and even to get them out again if you are just a bit of a handy man. If you are a professional carpenter, then you do indeed need other and more specific tools than just a screwdriver.

Likewise a programmer doing assignments in toy programs might get by with something as simple as printf statements, while the more serious programmer needs better tools.

This article is split in two parts. In first part I will introduce you to some of the common development tools which you may want to use for software development, these include development environment, editors, debuggers, version control systems, and systems for speeding up compilations. In the second part I will focus on some pretty advanced tools for finding memory errors, tracing memory usage, plus finding where time is wasted in your application. All these tools are based on an open source tool called valgrind

As part of my daytime job I'm giving courses in Qt programming , and have consequently seen a lot of people developing software, the environment in which they do so, etc.

Sometimes, I've seen people who would start vi , make some changes, quit it again, and compile in the shell, sees a syntax error reported from gcc , start vi again, and makes the changes, and so on. For each error they would spent 10 second to find the right file, find the right line and try an remember what the error was. To say the least this is not very efficient at all.

Thus when developing software, you have to make sure that your development environment is powerful enough to support your development cycle, both short term (as in compile cycle), and long term (as in merging conflicts resulting from several developers working on the same files).

People often ask me then, which editor they should choose, and even though my favorite editor is by far XEmacs, I don't want to get into any religious wars here. Choose the editor which you know, and become an expert with it - of course if your favorite editor is a simple and limited one, then you may consider changing.

Here are a few suggestions though. If you do not have a favorite editor already, then do consider KDevelop (see screen shot below), it is very powerful, very intuitive, and is being actively developed. If your favorite editor is Vim or one of the Emacs's, just fine, they are powerful enough for software development, just ensure that you get to be an expert with them

Remember the old story about two men cutting woods. One worked hard all day, while the other from time to time took a break. At the end of the day the person taking breaks would have - to the surprise of the other - cut more wood. When asked how that could be, he answered: "Every time I took a break, I sharpened my saw"

I urge you to think of your development environment as your saw , and from time to time spent some time learning about your development environment.

Unfortunately there are not much competitions for debuggers under Linux, which might also be the reason for the one and only existing debugger being only semi-good. For me personally it crashes up to tens times a day on busy debugging days. There are commercial debugger available for Linux, but as they are pretty expensive they are indeed only for professionals.

The debugger under Linux is called GDB, if you prefer you can run it directly from the command line. KDevelop has builtin support for GDB, here you simply click on a line to set a break point, and when execution stops at a break point, the editor will display that line for you.

Similar functionality exists for Emacs, with a bit more rough edge of course (setting breakpoints does not happen by clicking on the line, but rathe by pressing C-x space). Vim has a patch for this (called VimGDB), but otherwise you might choose to use another front end for GDB.

There does exists a few graphical front ends to GDB, the most prominent one being DDD. This might be a good candidate for debugging if you do not use KDevelop (which has similar functionality to DDD built in). Below you can see a screen shot of DDD in action.

Talking about running gdb from within Emacs or VIM, both also has support to run the compiler from within the editor. Under Emacs simply press M-x compile , while under VIM press :make . Under Emacs you jump to the next error by pressing C-x ` (i.e. the back ping), while under VIM you press :cnext .

When many people (that is more than one person) works together on a set of source code, it is of vital importance that the source files are managed by a revision system, which will handle the situation that two persons edits the same file.

Of course, an other important role for a version control system is the capabilities to figure out who changed what and when; being able to tag a number of files for release so you later can get back to that exact version, etc.

Several version control systems exists under Linux, the most widespread one is called CVS. It has some annoyances, but is stable like rocks (To my knowledge we never had much trouble with it in KDE).

Several free version control systems are actively being developed to replace CVS as the number one under Linux, some of these are subversion and arch . A number of commercial system also exists, among these are bitkeeper , perforce , SourceSafe , and ClearCase .

The best way to get your applications compiled fast is to buy an ultra fast multi processor machine with hundreds of processors.

Not an options? Well then the next best and for most mortals most feasible solution is to have a bunch of computers work together on compiling your application. Three tools exists for this:

Teambuilder and icecream are similar in functionality, with the only difference that teambuilder is more stable and commercial, while icecream is open source software. Distcc is a bit more stable than icecream, but its scheduling algorithm is round robin, where icecream and teambuilder tries to allocate the jobs to the best machine.

Having mentioned that icecream is not as stable as the others, its time to point out that we are not talking mission critical stuff here, so the scheduler crashing a few times a day is indeed not a disaster, and by the time you read this, the bugs are likely gone already, and its stable like rocks.

I'll therefore tell you a bit about icecream, as for most purposes this seems to be to be the best tool.

Icecream is very easy to use, here is how. On one machine you start the scheduler, and on all machines which should participate, you prepend the icecream directory to your path, which will ensure that the special versions of gcc, cc etc are in front of the normal ones. Next you must start the icecream daemon called iceccd . The compiler must be the same on all participating machines, but there are no requirements about having the same set of header files or libraries.

New machines can be put into the network without having to restart anything, and at any point any machine (except the scheduler) can be removed.

When compiling using make, you must add the compile flag -j to ensure that make issues more than one gcc compilation at a time. -j takes as an argument a maximum of simultaneous compilations, so if you have 5 machines participating, it might be an idea to specify -j 5 , to avoid that make prepares say 200 files to compile, just to realize that there was an error in the first one.

Icecream comes with a monitor, which can show you which machines is doing what. A screen dump of the monitor can be seen below.

As mentioned above, valgrind is a modular toolkit from which a number of tools are build. The fundamentals of valgrind is an X86 simulator, which simulates a real processor, and meanwhile measures certain things on your program.

The first tool we will look at is mem-check, a tool for tracing memory errors. Lets start with a small example from a very simple C program:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main( int /*argc*/, char** /*argv*/ ) {
    char* str = "Hello World\n";
    char* copy = (char*) malloc( sizeof(char) * strlen( str ) );

    strcpy( copy, str );
}
              

Take some time to look at the application above, if you can't spot the error within a millisecond, and if you think you could ever have made that error (and you could), then mem-check is indeed a tool for you.

The problem with the code above is that we allocate one byte too little for the copy of the string, namely the byte for the null terminating character. Nevertheless the strcpy function will copy over the null terminating character, and the result is that it writes beyond the boundary of the array allocated.

It is exactly this kind of problem that the mem-check tool for valgrind is created to detect (among a number of others of course). So lets try and see what valgrind says when invoked on the program above. To start valgrind with the mem-check tool, write a command similar to: valgrind --tool=memcheck < application-name > Below you can see the output from valgrind (Notice versions of valgrind older than 2.1.0 uses --skin rather than --tool )

==19989== Memcheck, a memory error detector for x86-linux.
==19989== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==19989== Using valgrind-2.1.1, a program supervision framework for x86-linux.
==19989== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==19989== For more details, rerun with: -v
==19989== 
==19989== Invalid write of size 1
==19989==    at 0x3C020CAA: strcpy (mac_replace_strmem.c:199)
==19989==    by 0x804855A: main (main.cpp:9)
==19989==  Address 0x3CE29060 is 0 bytes after a block of size 12 alloc'd
==19989==    at 0x3C021350: malloc (vg_replace_malloc.c:105)
==19989==    by 0x8048546: main (main.cpp:7)
==19989== 
==19989== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 49 from 1)
==19989== malloc/free: in use at exit: 360 bytes in 11 blocks.
==19989== malloc/free: 404 allocs, 393 frees, 9422 bytes allocated.
==19989== For a detailed leak analysis,  rerun with: --leak-check=yes
==19989== For counts of detected errors, rerun with: -v
              

Each line is prefixed with the process id of the processes printing out messages - this is useful as valgrind is capable of tracing subprocesses too (using the --trace-children=yes option).

Line 7 is where all the fun starts. Valgrind tells us that there has been an invalid write of one byte. The following lines are a back trace which shows up where this error occurred. But that's not all, on line 10 it tells us that the invalid write is zero bytes after another block, and then follows the backtrace telling us where that other block was allocated. Now it is a piece of cake finding and solving the problem.

Above we discussed the valgrind tool called memcheck and addrcheck, in the following we will look at another tool called calltree. Calltree was initially developed as a tool to annalize cache misses (cache as the fast memory computers have). It was, however, soon discovered that the data that calltree collected was also useful for a much broader audience. calltree output is namely useful for analysis of where time is spent in an application - which is also known as profiling.

calltree's output is viewed using an application called KCacheGrind. The procedure for profiling is to start the valgrind using a command similar to valgrind --tool=calltree < application > This will generate one or more files named cachegrind.out. <process-id >. Next you will start KCacheGrind giving it one of these file as argument.

calltree and kcahegrind are not shipped with valgrind, but must instead be downloaded and installed separately. You download calltree and KCacheGrind from http://kcachegrind.sourceforge.net/ .

The last tool from the valgrind suite we will have a look at is Massif. Massif is at the same time very simple and very useful. Massif will generate a graph showing at which time in your application how much memory has been allocated, and from which part of the application the memory was allocated. Simply run your application like valgrind --tool=massif . The snapshot below shows you what a massif graph looks like.