Goals for this week:

The topics of this week’s lab are a review of C++ programming, C/C++ programming tools, and Unix utilities that you will use in this course. We will go over some of these in lab, but you are responsible for reviewing all of the content on this page. This lab page includes information about:

  • Practice and reminders about C++ programming: statically and dynamically allocated objects, streams, vectors, compiling C++.

  • Practice with make and make files.

  • Reminders on command line arguments in C and C++ programs and the the atoi function.

  • Practice with C++ debugging tools: gdb and valgrind.

Starting Point Code

Start by creating a week01 directory in your cs44/weeklylabs subdirectory and copying over some files.

If you have not yet made your cs44/weeklylabs subdirectory do this first:

cd
mkdir cs44
cd cs44
pwd
  /home/you/cs44
mkdir cs44/weeklylabs
cd cs44/weeklylabs
pwd
mkdir /home/you/cs44/weeklylabs

Creat a week01 directory in your cs44/weeklylabs subdirectory and copy over some files:

cd ~/cs44/weeklylabs
mkdir week01
cd week01
pwd
  /home/you/cs44/weeklylabs/week01
cp ~newhall/public/cs44/week01/* .
ls

C++ Programming

We will go over a couple of programs. The first, in arrays.cpp, will go over several C++ concepts, including:

  • statically and dynamically allocated arrays in C++

  • parsing command line arguments

  • C++ constants

  • C++ stream output, and C printf output

We’ll look at this briefly together. Then, you will compile (run make) and execute the program with different command line options to make sure you understand how to use the command line arguments as well as atoi.

vim arrays.cpp
make
./arrays
./arrays 5 hello there 1234

Second, we will look at cstringExample.cpp, which will allow us to use valgrind to find memory access errors and memory leaks. We will also see a basic example of using c-strings.

gdb and valgrind to debug C++ programs

We are briefly going to go over just a few gdb and valgrind features to remind you how to use these tools. Next week, we will see how to set a breakpoint in method functions using ` (a single tick) followed by the start of class or method name prefix and TAB completion to easily specify long method function names.

GDB for C++ program debugging

We are going to look at some features of gdb for debugging C++ programs. In particular, looking at a stack trace, moving between frames to examine parameter and argument values, and examining runtime state of a segfaulting program.

Here is a directory of files you can copy over that can be used to test out some gdb features:

cd ~/cs44/weeklylabs
cp -r ~newhall/public/gdb_examples .
cd gdb_examples

First, run make to build the executables (note they are all compiled with -g flag to enable debugging).

Let’s look through a couple of the example programs in gdb, following along in my GDB Guide (a more verbose version of this is in Chapter 3 of Dive into systems).

I recommend running the gdb layout src command to get a split window view that shows the current execution point in the program code source along with the gdb prompt interface.

We are going to look at badprog and segfaulter in gdb. These are listed in the "Sample gdb sessions" part of my gdb guide:

Try: try gdb on one of the C++ examples you copied over. Try:

  1. configure gdb with layout src to enable the source code view

  2. set a break point in main

  3. set a break point at another location in the file.

  4. try run, step, and cont commands.

  5. examine some runtime state of variables using print and/or x.

Here is some information about common gdb commands. There are also gdb links off my GDB Guide.

Valgrind

valgrind is a tool for finding heap memory access errors and memory leaks in C and C++ programs. Memory access errors are often very difficult bugs to find, and valgrind helps you easily find errors like reads or writes beyond the bounds of a `malloc’ed array, accessing `free’ed memory, reading uninitialized memory, and memory leaks (not freeing `malloc’ed space before all variables referring to it go out of scope).

Above, we used valgrind for the cstringExample.cpp exercise. If you want some more practice, copy over these files that can be used to test out valgrind:

cd ~/cs44/weeklylabs
cp -r ~newhall/public/valgrind_examples .
cd valgrind_examples

To use valgrind, just compile with '-g', and run valgrind on your program (the Makefile has this already):

make
valgrind ./badprog

The output at first seems a bit cryptic, but once you see the basics of how to interpret it, it is extremely helpful for finding and fixing memory access errors. Let’s look at my Valgrind Guide (or a more verbose version of this in Chapter 3 of Dive into Systems) to see how to interpret some of this valgrind output. This guide contains links to other valgrind resources, and the README file in the code you copied over lists some command line options for running valgrind.

C++ Code Style

Read my C++ Code Style Guide. You do not need to follow my naming style exactly, but pick a convention and follow it. All classes and method functions should be fully commented. You should write complete function comments in both .h and .cpp file. One way to do this is to write them in the .h file first, copy the .h file contents to the .cpp as a starting point for writing method function implementations. Also, if you use globals and constants, comment them as well.

I also really hate wrapped lines. Don’t do it. See my guide for some techniques to avoid it. If you are using vim, you can copy my .vimrc file that has some visual reminders when you get to the 80th column. Here is some more information about how to do this vim editor.

Other Utilities

We are not going to go over these in class, but here are some reminders about using make and makefiles and man.

Using man and apropos

Here is some information about how to read manual page using man and how to find commands and library functions using apropos: unix manual, man, apropos from Appendix 2 of Dive into Systems.

Try looking at the man page for fork to see how it is telling you information about the fork function: how to call it; what header file(s) to be included to call it; and what the function does and what its return value(s) are.

man fork
# or, I could specify the man section...I don't need to for fork:
man 2 fork   # the man page for the system call fork in section 2 of the manual

C++ library functions do not have man pages, but we will use some C library functions in lab assignments and some Unix commands, both of which have man pages.

make and makefiles

Here is some information about using make and makefiles to build executables:

We will give you make files with all of your lab assignments, but you should take some time to be sure you are familiar with using make, and be used to running make to compile your lab code, and make clean before adding file changes in git to avoid adding any files to your repo that are built from source code (i.e. .o and binary executable files).

Handy References