1. 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 have used before and 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.

2. 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
mkdir weeklylabs

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

3. C++ Programming

We will go over a couple of programs. The first, in arrays.cpp, will go over several {cpp 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.

4. 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. I’ll also show you how to set breakpoint in method functions using '\'' and TAB completion to easily specify long method function names.

4.1. 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

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

Let’s also try setting a break point in the C++ example code you copied over. Make use of `gdb’s tab completion to list the names of class methods.

Up the page on this guide are lists of common gdb commands and some examples of how to use them.

4.2. 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 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.

4.3. 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 vim editor.

5. Other Utilities

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

5.1. 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: man and apropos

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.

5.2. make and makefiles

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

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).

6. Handy References