1. Goals for this week:

The topics of this week’s lab are a review of C and C++ programming tools and utilities that you have used before and that you should use when solving lab 0. We will not talk about all of these in lab, but this page contains some links to resources about:

  1. Practice and reminders about C++ programming: inheritence, statically and dynamically allocated objects, stream, vector, compiling C++.

  2. Practice with make and make files.

  3. Remember how to access command line arguments in C and C++ programs the atoi function

  4. Remember and 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/weelylabs subdirectory do this first:
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 are going to look at the Employee and Manager class briefly. This is an example that uses C++ features: inheritance, vector, string, cout, virtual methods, constant definitions, and pass-by-pointer examples.

4. 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. 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 know how to use make, and be used to running make clean before adding file changes in git to avoid adding any files to your repo that are built from source code (like .o an binary executable files).

6. gdb and valgrind to debug C++ programs

We are briefly going to go over just a couple of gdb and valgrind features to remind you how to use these. I’ll also show you how to set breakpoint in method functions using '\'' and TAB completion to specify long method function names.

6.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. You can use ddd if directly logged into our system, but I’m going to show you the gdb commands running gdb.

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

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 under

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.

6.2. Valgrind

cd into the valgrind_examples subdirectory.

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

Here are some files you can copy over 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.

6.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. With the exception of very simple getter and setter methods, all classes and method functions should be fully commented. Also, if you use globals and constants, comment these as well. 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.

I also really hate wrapped lines. Don’t do it. See my guide for some techniques for avoiding 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 {remoteurl}#vim[vim editor].

7. Handy References